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
on 30.03.2008 16:23
on 30.03.2008 19:57
> 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 Cottenceau - http://zarb.org/~gc/
on 30.03.2008 20:21
On Sun, Mar 30, 2008 at 07:56:38PM +0200, Guillaume Cottenceau 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 :) Sjoerd -- The herd instinct among economists makes sheep look like independent thinkers.
on 31.03.2008 17:07
Hi, In <20080330142259.GA16453@beast.luon.net> "[ruby-gnome2-devel-en] [patch] Fix ruby-glib thread handling" on Sun, 30 Mar 2008 16:22:59 +0200, Sjoerd Simons <sjoerd@luon.net> 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 05.04.2008 17:42
On Tue, Apr 01, 2008 at 12:06:47AM +0900, Kouhei Sutou 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 :) (It also wasn't threadsafe in the patch i attached earlier btw) Sjoerd
on 05.04.2008 17:59
Hi, In <20080405154056.GA17128@spring.luon.net> "Re: [ruby-gnome2-devel-en] [patch] Fix ruby-glib thread handling" on Sat, 5 Apr 2008 17:40:56 +0200, Sjoerd Simons <sjoerd@luon.net> 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