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.