Jari Williamsson
1/25/2008 9:29:00 AM
daniel åkerud wrote:
> On Jan 24, 2008 10:11 PM, Daniel Berger <djberg96@gmail.com> wrote:
>
>> On Jan 24, 1:52pm, "daniel åkerud" <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 data
> 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?
Yes, that would work if you make the data queue thread safe, probably
using a Windows mutex (and wait with no timeout duration in the Ruby
thread).
Best regards,
Jari Williamsson