[patch] Fix ruby-glib thread handling

Hi,

Attached patch fixes the way ruby-glib handles signals from threads.
This
means it reverts to using a pipe like system so the main ruby thread
can
select on it to ensure it runs when needed. The main difference that
is that
we use IO.pipe instead of pipe() to create the pipe, which should make
the
code portable. I also added a test-case showing the effect, it would
be nice
if someone could test this on a win32 system just to be sure

Sjoerd

Attached patch fixes the way ruby-glib handles signals from threads. This

From Ruby threads, you mean? Is there any evidence that calling Gtk
stuff from Ruby threads is now safe? It has never been, for as long as
I’ve been using rg2 (several years) - check archives for details if
needed…


Guillaume C. - http://zarb.org/~gc/

On Sun, Mar 30, 2008 at 07:56:38PM +0200, Guillaume C. wrote:

Attached patch fixes the way ruby-glib handles signals from threads. This

From Ruby threads, you mean? Is there any evidence that calling Gtk
stuff from Ruby threads is now safe? It has never been, for as long as
I’ve been using rg2 (several years) - check archives for details if
needed…

This isn’t about calling Gtk stuff from ruby threads. This is for
handling
signals from native threads, which tends to happen in gstreamer programs
reasonly often. What you do in the actual callback still has to be safe.
Gstreamer things are fine, Gtk things are usually problematic indeed.

But yeah, native vs. ruby threads are confusing from time when
describing stuff
:slight_smile:

Sjoerd

The herd instinct among economists makes sheep look like independent
thinkers.

Hi,

In [email protected]
“[ruby-gnome2-devel-en] [patch] Fix ruby-glib thread handling” on Sun,
30 Mar 2008 16:22:59 +0200,
Sjoerd S. [email protected] wrote:

Attached patch fixes the way ruby-glib handles signals from threads. This
means it reverts to using a pipe like system so the main ruby thread can
select on it to ensure it runs when needed. The main difference that is that
we use IO.pipe instead of pipe() to create the pipe, which should make the
code portable. I also added a test-case showing the effect, it would be nice
if someone could test this on a win32 system just to be sure

It’s simple that we use _pipe() on Windows rather than using
IO.pipe.

Thanks,

On Tue, Apr 01, 2008 at 12:06:47AM +0900, Kouhei S. wrote:

code portable. I also added a test-case showing the effect, it would be nice
if someone could test this on a win32 system just to be sure

It’s simple that we use _pipe() on Windows rather than using
IO.pipe.

Ah nice, i’ll do something similar in the threaded gstreamer calls
then. The
only problem with your patch i saw is that you do the pipe() call
inside the
created ruby thread. Which means it’s not guaranteed that it will be
done
when the first signal comes in (or at least afaik rb_thread_create
does not
guarantee the created thread will be executed first). So a little fix
for
that attached.

Also stopping the callback thread is not really thread safe. But it’s
not
that important imho, so i didn’t spent time on fixing that :slight_smile: (It also
wasn’t
threadsafe in the patch i attached earlier btw)

Sjoerd

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] [patch] Fix ruby-glib thread handling” on
Sat, 5 Apr 2008 17:40:56 +0200,
Sjoerd S. [email protected] wrote:

we use IO.pipe instead of pipe() to create the pipe, which should make the
guarantee the created thread will be executed first). So a little fix for
that attached.

Please commit your patch.

Thanks,

kou

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs