From: MenTaLguY <mental@...>
Date: 2007-12-11T07:49:08+09:00
Subject: Re: Compliment to rb_thread_blocking_region() ?

On Tue, 11 Dec 2007 06:41:56 +0900, "Tony Arcieri" <tony@clickcaster.com> wrote:
> I'm curious if there's a way to make calls back into Ruby inside of the
> callback function that's passed as an argument to rb_thread_blocking_region().

> That is to say, is there a complimentary function to rb_thread_blocking_region
> which takes a C callback function and acquires the GIL (letting you call back
> into Ruby) then releasing it when it's done.

There is no public API to re-enter the interpreter at this time.  Besides
acquiring the GIL, there are two other issues which would need to be addressed:

 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.)

 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.

The second issue shouldn't be a problem for your libevent use case (and is
easier to solve anyway), but I'm not sure of a good solution to the first.

So, right now, in the general case, the best you can do is have a Ruby thread
consuming work items submitted to a native work queue by callbacks running in
other threads.

For libevent specifically, you should consider using event_loop() rather than
event_dispatch(); your C callback could then simply record the work item
somewhere which will be accessible after event_loop() returns, and the actual
work could be performed once you are back in the interpreter.  That avoids the
need for a work queue and the associated extra context switches/synchronization.

-mental