Re: GVL lock and unlock

On Tue, Apr 17, 2012 at 3:15 AM, I=F1aki Baz Castillo <[e-mail]> wrote=
:

> BTW: During the libuv event loop, Ruby callbacks will be called.
> Should I take the GVL before invoking them?


Yes, definitely, you want to have the GVL released for as little time as
possible, and when it is released you should only be doing things in memory
you allocated yourself from C.

I ran into similar problems with rb_thread_blocking_region() writing a
wrapper for libev (well, twice now, once with cool.io and once with nio4r)
as its API mandates a function pointer, as opposed to the sort of
GVL_UNLOCK_BEGIN/END
macros that you would expect. This is a problem, because the libev API
provides before/after callbacks that happen around the system call (e.g.
epoll) that would be great for unlocking and relocking the GVL.

I understand this API was not provided because it was considered too
dangerous, but it was really needed for libev. I wonder if you'll encounter
the same problems with libuv. I really wish there were a
GVL_EXTREMELY_DANGEROUS_USE_WITH_CARE_UNLOCK_BEGIN/END macro ;)

I ended up having to patch the libev source code and put
rb_thread_blocking_region() right into the heart of the event loop.

--

BTW, what kind of wrapper are you doing for libuv? Are you going for a
comprehensive one, or only wrapping part of the functionality?

I'd love to add libuv into the next release of nio4r (it already uses libev
for a selector API). libuv could be used to do direct buffers on the C side
the same way Java NIO can do them on the Java side.

--=20
Tony Arcieri