You don't need to make @blocking = true conditional - its just setting
an ivar on the module, which ffi on mri looks at, but doesn't need to
on jruby (or any other impl that doesn't support it).

Its also non-sticky - it gets reset to false after each call to attach_function.



On 13 May 2010 11:36, Chuck Remes <cremes.devlist@mac.com> wrote:

> For a few choice functions, I added the following line per your suggestion:
>
> @blocking = true unless RUBY_ENGINE == "jruby"
>
> That has eliminated the remaining weird behavior (so far). I'll run everything through a full batch of tests this weekend to confirm it is more solid (is any code truly trouble-free?).
>
> Thanks again for your help. I will try to document this latest snippet on the wiki.
>
> cr
>
>
> On May 12, 2010, at 8:27 PM, Wayne Meissner wrote:
>

>> Depends on what the "weird" behaviour is.  The other half of the
>> threading equation, is calling native functions which block (i.e.
>> sleep, wait for I/O, take a long time to complete, whatever).
>>
>> In JRuby, its not a problem, since it has real threads and no GIL, but
>> for MRI (once again, 1.9 only, ffi from master), you can add the
>> @blocking attribute when you attach your functions, like so:
>>
>>  @blocking = true
>>  attach_function :zmq_whatever, [ ... ], :rtype
>>
>> That is a hint to FFI that the function could block, and it should
>> release the GIL before calling it.  Thats a bit of a performance hit,
>> which is why its functions are not assumed to be blocking by default.
>>
>>
>> On 13 May 2010 10:36, Chuck Remes <cremes.devlist@mac.com> wrote:

>>> That fixed the crashes with 1.9.1 but I am still seeing some odd behavior. It may be a bug on my side, so I'll play with it a while longer.
>>>
>>> Many thanks...
>>>
>>> cr
>>>
>>> On May 12, 2010, at 6:29 PM, Wayne Meissner wrote:
>>>

>>>> Can you build ffi from github and retry it on 1.9?  I added special
>>>> support for callbacks from non-ruby threads (only works on 1.9 though
>>>> - 1.8 is completely screwed in that situation).
>>>>
>>>> JRuby has no problem, because upcalls from C -> java always check &
>>>> attach a JVM context, and jruby automagically adopts threads it does
>>>> not know about.

>
>