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.
>>
>>
>> On 13 May 2010 05:53, Chuck Remes <cremes.devlist@mac.com> wrote:

>>> I'm starting to work with callbacks and have run into a consistent crasher. Take a look at the trace here:
>>>
>>> http://gist.github.com/398987
>>>
>>> I downloaded the ruby-1.9.1 source and poked through vm_eval.c which contains the vm_call0() function. There is a big switch statement in there that falls through to calling rb_bug().
>>>
>>> This all occurs *only* when invoking the callback. The stack trace clearly shows it is invoking a block (rb_funcall2) from the FFI library. It crashes regardless of the contents of the block (empty, puts, nil, etc.).
>>>
>>> In 1.8.7 it crashes with a LocalJumpError somewhere else.
>>>
>>> When I disable the callback, there are no crashes under either MRI.
>>>
>>> Under JRuby, everything works fine. The callback is invoked successfully.
>>>
>>> I'm wondering if this is failing because the callback may be invoked by another native thread. The library being wrapped by FFI spawns many threads that do various background tasks; one of them is likely the invocation of the cleanup callback that is causing the crash.
>>>
>>> Are there any known issues with MRI, FFI and callbacks?
>>>
>>> cr
>>>
>>>

>
>