From: Tony Arcieri Date: 2007-12-11T08:31:52+09:00 Subject: Re: Compliment to rb_thread_blocking_region() ? ------=_Part_5468_22617467.1197329514889 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Dec 10, 2007 3:49 PM, MenTaLguY wrote: > 1. Ruby would need some way to safely unwind the stack past the native > code > that (re-)entered the interpreter (e.g. due to a raised exception, > throw, thread kill, etc.) > How would it be different from what rb_funcall() does already? 2. Calling into the interpreter from a non-Ruby thread would require that a > "Ruby identity" be established for that thread for the sake of Ruby's > scheduler and also its garbage collector. Currently, Ruby relies on > the special setup it does when creating its own threads. > Well, the goal with something like libevent would be to start inside Ruby, set up a callback receiver object, and pass a handle to that callback receiver object to the blocking call in the native extension. The native extension would then block for the duration of libevent's loop running (e.g. until something told it to stop), then have the libevent callbacks make rb_funcall()s to the original callback object from Ruby. So, at least in this case you'd be starting in Ruby and using only on a thread where the "Ruby identity" has been established prior to calling out to the blocking C function. -- Tony Arcieri ClickCaster, Inc. tony@clickcaster.com ------=_Part_5468_22617467.1197329514889 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Dec 10, 2007 3:49 PM, MenTaLguY <mental@rydia.net> wrote:

1. Ruby would need some way to safely unwind the stack past the native code
that (re-)entered the interpreter (e.g. due to a raised exception,
throw, thread kill, etc.)

How would it be different from what rb_funcall() does already?

2. Calling into the interpreter from a non-Ruby thread would require that a
"Ruby identity" be established for that thread for the sake of Ruby's
scheduler and also its garbage collector. Currently, Ruby relies on
the special setup it does when creating its own threads.

Well, the goal with something like libevent would be to start inside Ruby, set up a callback receiver object, and pass a handle to that callback receiver object to the blocking call in the native extension. The native extension would then block for the duration of libevent's loop running ( e.g. until something told it to stop), then have the libevent callbacks make rb_funcall()s to the original callback object from Ruby.

So, at least in this case you'd be starting in Ruby and using only on a thread where the "Ruby identity" has been established prior to calling out to the blocking C function.

--
Tony Arcieri
ClickCaster, Inc.
tony@clickcaster.com ------=_Part_5468_22617467.1197329514889--