Callbacks wiki page: section about "GIL" seems junky

[David Grayson]

Hello.

I recently added the "C callbacks" section to the Callbacks page in the FFI Wiki.

The section below that, entitled "GIL", seems pretty junky to me and likely to be wrong.  The author is listed as "chuckremes" in the Revision history but I cannot figure out how to contact him.  I was hoping an FFI developer would take a look at that Wiki section and help me fix it up, since there may be some important information in there that should be expressed properly.

The GIL section starts off with a good sentence:

There may be situations where the callback function is another C function in the library. 

Unfortunately, it doesn't have a code example for how to do that, instead it launches into a super technical discussion without adequate background:

In this case it may not make any sense to retain the Ruby GIL when there is no need to protect the Ruby runtime from a thread race.

So, who is retaining the Global Interpreter Lock, and why?  I imagine the GIL is actually released before any call into an FFI C function, but I am not sure.  I imagine that the GIL would be reacquired in the FFI callback stub before it calls a Ruby Proc.  But since we are not using a Ruby Proc, and just using a C function pointer instead, that GIL reacquisition feature doesn't matter.  So this sentence does not make sense to me.

The next sentences in the section are:

Releasing the GIL will allow the Ruby runtime to (potentially) schedule another thread to run and complete more work. Luckily, FFI::Function allows us to optionally release the GIL by marking the callback as blocking. This setting only affects Ruby-to-native calls; it has no effect for native-to-Ruby calls.

I couldn't find any documentation on the :blocking parameter in the FFI:Function RDoc documentation.  If it exists, it would be nice to add it to RDoc, and if it doesn't exist, then this Wiki section is just wrong.

After that, the Wiki section says how you can construct a Ruby callback using FFI:Function with the :blocking parameter.  But we don't want a Ruby callback because in the very first sentence of the GIL section we set up the situation where the callback function is another C function in the library.

So, am I misunderstanding something, or is that section just wrong?  I didn't want to just edit that section myself in case I was missing something.

--David

[Charles Oliver Nutter]

I'm not yet sure the section is *wrong* but it's specific to one Ruby
implementation and most of the gory details aren't directly relevant
to callbacks.

Perhaps we should pull most of the GIL discussion out to another page
with a link saying something like "If you run on MRI/CRuby, you should
be aware of how FFI interacts with MRI's global lock."

- Charlie

> --
> You received this message because you are subscribed to the Google Groups
> "ruby-ffi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ruby-ffi+u...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ruby-ffi.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ruby-ffi/f02782c7-808c-4d0d-b29c-b2f8224d84fe%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.