From: "daniel åkerud" <daniel.akerud@...>
Date: 2008-01-25T07:06:10+09:00
Subject: Re: Using a DLL that wants a function pointer

------=_Part_24393_1633404.1201212375333
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Jan 24, 2008 10:11 PM, Daniel Berger <djberg96@gmail.com> wrote:

> On Jan 24, 1:52pm, "daniel =E5kerud" <daniel.ake...@gmail.com> wrote:
>
> <snip>
>
> > I think this is important in this context: The callback is called from
> > another thread, i.e. the DLL creates a thread that reads data in the
> > background, and when data arrives it calls the callback. Would this be =
a
> > problem if the Ruby extension calls the Proc object from another thread=
,
> and
> > if so, how to solve it...
>
> At the moment, you don't. Windows callbacks occur in their own native
> thread. The Ruby interpreter isn't thread safe. You'll get one
> callback call to work, but after that it will probably segfault.
>
> Heesob is working on this for the C side of the house to see if he can
> come up with a way to make it work. In the meantime, I'm going to see
> if I can get win32-api ported to JRuby using JNA this weekend. That
> *should* work, though it means you'll have to use JRuby to use it,
> which may not be such a bad thing. :)
>
> Regards,
>
> Dan
>
>
What if I provide a polling-mechanism, i.e. the Ruby-extension puts all dat=
a
from the callback in a queue, and the Ruby-script poll()s periodically to
see if there is any data. In this case, to Ruby, everything will happen in
the same thread. Indeed this removes the callback interface Ruby-Script ->
Ruby-Extension (which indeed is the subject...), but it circumvents the
threading-problem. Would it work?

/D

------=_Part_24393_1633404.1201212375333--