Hi Folks,
I’ve been fighting this issue for some time now, and I’ve been reading
all of the recent posts regarding how Ruby’s threading model can fight
with other “real” threads due to stack corruption.
However, I see random crashes when I’m using embedded browsers (gecko or
webkit) in my application. I’m guessing that it has to do with the fact
that my callbacks might be triggered while some of the browser’s own
threads are still operating (I’m not doing anything tricky, just
handling nearly every signal).
I’ve been meaning to try and dig into this issue a bit more to see if I
can come up with a better threading solution, but I haven’t gotten the
time. However, it’s extremely annoying, and it is certainly something
that would keep this application from being ready for prime time.
Has anyone else observed this behavior and/or does anyone have any
suggestions as to how to try and keep it from happening?
excalibur$ ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]
I’m using a relatively recent WebKit build (from a couple of weeks ago),
and the versions of the gecko development libs current with Ubuntu 8.0.4
with ruby-gnome2 that’s been built from source.
Thanks in advance for any ideas or info.
Cheers,
ast
Andrew S. Townley [email protected]
http://atownley.org
On Tue, Apr 21, 2009 at 11:45 AM, Andrew S. Townley [email protected]
wrote:
handling nearly every signal).
If you mean that gecko or webkit may trigger callbacks of your
application not from the main ruby thread, and you call some ruby-gtk
functions from these callbacks, then you need to change that behaviour
and make sure the ruby-gtk functions are call from the main ruby
thread.
If your gtk callbacks are called while some unrelated threads of gecko
or webkit are doing some job, it should not create problems.
–
Guillaume C. - Guillaume Cottenceau
On Thu, 2009-04-23 at 12:07 +0200, Guillaume C. wrote:
threads are still operating (I’m not doing anything tricky, just
handling nearly every signal).
If you mean that gecko or webkit may trigger callbacks of your
application not from the main ruby thread, and you call some ruby-gtk
functions from these callbacks, then you need to change that behaviour
and make sure the ruby-gtk functions are call from the main ruby
thread.
In theory, this shouldn’t be possible. All of the callback routines use
the Gtk.queue approach to try and do exactly what you say. That’s part
of the reason that I’m so frustrated…
If your gtk callbacks are called while some unrelated threads of gecko
or webkit are doing some job, it should not create problems.
That’s the behavior I’d expect. Admittedly, I’m kinda grasping at
straws here because I’ve tried to ensure that I’ve followed all the
guidelines for threading using GTK that I could, but I still get
occasional segfaults. It doesn’t happen with any predictable way, which
is why I’m guessing there’s some sort of threading issues at work here.
At the moment, I’m in the process of refactoring the application to once
again attempt to ensure things are playing by the rules and do some
general clean-ups, so maybe I’ll fix it by “accident”, but I doubt it.
Thanks for the suggestions.
Cheers,
ast
Andrew S. Townley [email protected]
http://atownley.org