[ruby-core:85531] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid

[e-mail] 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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>