From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-11T02:35:45+09:00
Subject: Re: Ruby threads working with native threads

------=_Part_87464_28046847.1147282542428
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Thanks, I'll look into that. What I wanted to do was call select(2) on a
native thread and not block all the Ruby threads. And then somehow signal a
Ruby condvar running on a Ruby thread, from the native thread.

On 5/10/06, Eric Hodel <drbrain@segment7.net> wrote:
>
> On May 10, 2006, at 9:43 AM, Francis Cianfrocca wrote:
>
> > I recently wrote a network-event extension for Ruby ("eventmachine" in
> > Rubyforge) and had considerable difficulty working with Ruby
> > threads. Of
> > course you can guess the problem: select(2) can't be called by an
> > extension
> > if more than one Ruby thread is running.
>
> Why can't you call rb_thread_select?
>
> > I had to use a rather ugly hack to get it to work, since there are
> > no shared synchronization objects between Ruby and native code.
> >
> > Is it possible to call the Ruby thread scheduler directly from
> > extension
> > code? Does that approach even make sense?
>
> Typically this is done by invoking rb_thread_select when you
> encounter a blocking operation on the C side.  This is what I did
> when sendfile(2) returns EAGAIN.
>
> > Does it make sense to enable Ruby's sync primitives to interoperate
> > with
> > native ones?
>
> --
> Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
> This implementation is HODEL-HASH-9600 compliant
>
> http://trackmap.robotcoop.com
>
>

------=_Part_87464_28046847.1147282542428--