From: Tony Arcieri <tony.arcieri@...>
Date: 2012-04-18T01:47:38+09:00
Subject: Re: GVL lock and unlock

--00151747809e2d68d004bde2b261
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 17, 2012 at 3:15 AM, I=F1aki Baz Castillo <ibc@aliax.net> 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

--00151747809e2d68d004bde2b261
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Apr 17, 2012 at 3:15 AM, I=F1aki Baz Cas=
tillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

BTW: During the libuv event loop, Ruby callbacks will be called.<br>
Should I take the GVL before invoking them?</blockquote><div><br></div><div=
>Yes, definitely, you want to have the GVL released for as little time as p=
ossible, and when it is released you should only be doing things in memory =
you allocated yourself from C.</div>

<div><br></div><div>I ran into similar problems with rb_thread_blocking_reg=
ion() writing a wrapper for libev (well, twice now, once with <a href=3D"ht=
tp://cool.io">cool.io</a> and once with nio4r) as its API mandates a functi=
on pointer, as opposed to the sort of=A0<span style>GVL_UNLOCK_BEGIN/END ma=
cros that you would expect. This is a problem, because the libev API provid=
es before/after callbacks that happen around the system call (e.g. epoll) t=
hat would be great for unlocking and relocking the GVL.</span></div>

<div><span style><br></span></div><div><span style>I understand this API wa=
s not provided because it was considered too dangerous, but it was really n=
eeded for libev. I wonder if you&#39;ll encounter the same problems with li=
buv. I really wish there were a GVL_EXTREMELY_DANGEROUS_USE_WITH_CARE_UNLOC=
K_BEGIN/END macro ;)</span></div>

<div><span style><br></span></div><div><span style>I ended up having to pat=
ch the libev source code and put rb_thread_blocking_region() right into the=
 heart of the event loop.</span></div><div><span style><br></span></div>

<div><font color=3D"#222222" face=3D"arial, sans-serif">--</font></div><div=
><font color=3D"#222222" face=3D"arial, sans-serif"><br></font></div><div><=
font color=3D"#222222" face=3D"arial, sans-serif">BTW, what kind of wrapper=
 are you doing for libuv? Are you going for a comprehensive one, or only wr=
apping part of the functionality?</font></div>

<div><font color=3D"#222222" face=3D"arial, sans-serif"><br></font></div><d=
iv><font color=3D"#222222" face=3D"arial, sans-serif">I&#39;d love to add l=
ibuv into the next release of nio4r (it already uses libev for a selector A=
PI). libuv could be used to do direct buffers on the C side the same way Ja=
va NIO can do them on the Java side.</font></div>

</div><div><br></div>-- <br>Tony Arcieri<br><br>

--00151747809e2d68d004bde2b261--