sam.saffron / gmail.com wrote:
> Having discussed this with Koichi I think he is wanting to
> merge this into core but the big blocker here is naming and
> some small details. 

I'm leaning towards Thread::Green, so existing users can do
s/Thread.new/Thread::Green.new/ in many cases.

But, it would be easier if somebody good at API design (matz)
chimed in :>


Meanwhile, I think get rid of floating point timeouts:
https://bugs.ruby-lang.org/issues/14431
Then it might be easier to work on Queue/Mutex/... support.

> > One question, is how will Thread#[]/#[]= be handled inside the lambda?
> 
> I think it should be simply treated as a Thread global so it is shared between the lambdas. 
> 
> If you need lambda specific storage we could implement something else. Otherwise it complicates stuff.

That's probably too incompatible; I think the current Fiber#[]/#[]=
behavior is fine (Thread::Green implemented as subclass of Fiber)

> One big question I have though is how rb_thread_call_with_gvl
> and rb_thread_call_without_gvl will be handled, cause without
> magic handling there we don't get free PG / MiniRacer support
> and many others which is a huge shame.  

I expect PG to be able to benefit from rb_wait_for_single_fd when
using sockets.  I know mysql2 uses rb_wait_for_single_fd, at least.

rb_thread_call_* is meant for CPU (or FS/memory)-bound tasks,
and wouldn't MiniRacer be CPU-bound?  Dunno much about it...

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>