First, since all Ruby code (in 1.8.6 at least) runs from within the
same system thread, why does GTK care about which Ruby thread it is
called from? Don’t all Ruby threads just appear to be one thread to
GTK?
Second, the tip says that we must call GTK methods from within the
main thread. Is it possible instead to use the Gdk::Threads.enter and
Gdk::Threads.leave to surround GTK code? Other GTK bindings (PyGTK and
Java-GNOME) have used these methods:
Finally, does anyone know a quick way to make Ruby-GNOME segfault with
threads? Because I’d like to test out how these things work for
myself, so I can understand the techniques better.
Unfortunately the solution described in this page is not very
“environment”
friendly. As far as I understand, It forces the main loop to wake up 10
times per second and prevents the CPU to remain in idle, low-consumption
mode. This is still acceptable for a desktop-PC but totally unacceptable
for
a mobile device because the battery would be sucked up very fast.
(Would you have thought that you can have an impact on global warming
with
your little Ruby app?
For lack of anything better, I’m still using the solution described in
this
page in my application but I hope someone come up with an ideal solution
because I would like my application to run on Maemo.
From: Daniel L. [email protected]
Date: Wed, 11 Feb 2009 20:25:11 +0000
First, since all Ruby code (in 1.8.6 at least) runs from within the
same system thread, why does GTK care about which Ruby thread it is
called from? Don’t all Ruby threads just appear to be one thread to
GTK?
Ruby 1.8 threads are implemented by replacing the stack’s contents.
So during different ruby thread is running, the stack is inconsistent
from GTK viewpoint. If GTK code meets this inconsistent stack,
segmentation fault could happen.
Ruby 1.8 threads are implemented by replacing the stack’s contents.
So during different ruby thread is running, the stack is inconsistent
from GTK viewpoint. If GTK code meets this inconsistent stack,
segmentation fault could happen.
I see. That makes a lot more sense, thankyou.
Dobai-Pataky Bálint wrote:
hi, i attached an old test of mine,
it does not segfault with 0.18.1,
but exits with an error.
hope it helps.
Does this mean that GLib now has an improved error handling for these
thread failure situations? Would it be possible for us to catch this
error somehow in Ruby code? That would certainly make debugging
easier, especially when you don’t control all the code you’re running.
Thanks for the responses guys, sorry it took me so long to get around
to thanking you.
