From: Eric Wong Date: 2018-02-13T22:39:27+00:00 Subject: [ruby-core:85531] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid sam.saffron@gmail.com wrote: > > How long does it release the GVL for? > I would see it heavily depends on workload, but usually for > our loads it is milliseconds for v8 work, in PGs case shortest > duration is probably 0.5ms with a median more around 4-5ms It looks like currently pg is in the same boat as filesystem access (which sucks): the GVL release overhead for file.c and dir.c operations in 2.5 is painful to stomach on fast SSDs; but they make dealing with HDDs, network FSes and USB/MMC devices tolerable... But yeah, synchronously waiting on read/write from the Pg sockets is a total waste of native thread resources. (to that end, I still want to get rid of the GVL because it slows down those operations in single-threaded mode) > I would like to expand on the auto scheduler question here with a code example: > > ``` > t1 = Thread::Green.new do > while true > end > end > > t2 = Thread::Green.new do > puts "hi" > end > > t1.stop > > ``` > > I think the general expectation here is for this to output "hi" just like standard threads do. Earlier messages from ko1 indicated he favors fewer opportunities where scheduling happens: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/81495 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/81507 I definitely do not like switching at unpredictable points; I would only want to switch when the current execution context cannot proceed immediately. > I think we should probably support a ninja mode > > `Thread::Green.automatic_scheduling = false` Global switches like that probably lead to unpredictable code across libraries. Maybe per-thread or per-block options would be better; but even then libraries might get confused or thrown off by it. However, if existing code all assumes timeslice-based scheduling; maybe per-block/per-thread isn't so bad. > Or something like that if we just want the fiber auto yield > and nothing else, but the default should be safe. "safe" is a relative term :) Working on https://bugs.ruby-lang.org/issues/14357 was yet another reminder of why I don't like switching execution contexts at unpredictable points. > Clearly safety is going to have to be somewhat limited until > Fibers can move between threads cause you can be lost in C > land. Not sure what you mean by that. > Wondering what Matz and Koichi are thinking here? ko1 has given some hints on this thread; and I remember reading a developer's meeting summary where matz didn't want people to massively rewrite their code to take advantage of this new feature. > Totally support mutex, cv and queue being green thread aware. > Also would like to see that native timer which is green thread > aware. 1. Thread::Green will have timeslice scheduling, 100% compatible API-wise with built-in mutex/cv/queue/etc and pure-Ruby code 2. pipe and sockets become O_NONBLOCK by default (as in 1.8) when created inside green threads. 3. rb_thread_blocking_region - uses a native thread pool transparently inside green threads. This pool can auto-grow/shrink but the bound is the total number of green threads in the system. It's safe to use a big upper bound for existing applications since they already expect heavyweight native threads from 1.9+. We will fix+reuse USE_THREAD_CACHE hidden in current source to manage this thread pool. 4. introduce Thread options to give users ability to: - force rb_thread_blocking_region to run in the current native thread - disable timeslice-based switching Disabling timeslice-based scheduling should become an option with native threads, too. While writing this email, I considered making Thread green-by-default while doing the items 2-4 above; but C extensions relying on pthread_{get,set}specific would be broken by the transparent thread pool. Unsubscribe: