On Fri, 25 Feb 2005 20:55:17 +0100
Mirko Maischberger <mirko@...> wrote:
> Masao Mutoh wrote:
> > I noticed some issues if Mirko patches applied.
> > * It seems Gdk::Threads.init is required before calling Gtk.init
> > if you need to use Thread(Ruby) and the threads call Gtk/Gdk methods.
> > #If you don't call Gdk::Threads.init, the widgets aren't updated
> > #unless expose-event(mouse moving, focus the window, etc).
> This is not clear to me since Thread(Ruby) are implemented with a single
> native thread, there should be no native-thread switching, but only
> ruby-thread switching (inside a single real-thread). If there are no
> native-threads then Gdk::Threads.init should not be called (AFAIK).
> I think the issue with updating is related with not calling Gdk.flush
> and i can't find a stable relation with gdk_threads_init.
No. Try it again.
Actually, it doesn't update the widget, even you call Gdk.flush unless
to call Gdk::Threads.init.
So, at least, you have to call Gdk::Threads.init first.
You can reproduce this problem to use threads.rb.
> > -(e.g.)-----------
> > require 'gtk2'
> > Gdk::Threads.init
> > Gtk.init
> > -------------------
> > * Gdk::Threads.enter/leave seems not to work.
> > I don't know this is a part of the ruby thread/pthread problems.
> In the mail "About threads" i missed the point that ruby threads are not
> native-threads. So you should just forget that mail :)
I tested it by myself. It's not from your mail.
> I tried to use Gdk::Threads.enter/leave, but thoose method should create
> deadlocks if used "correctly" (called before gtk_init/main and inside
> any other thread).
Yes. I had a same result in my test script.
> In Gtk+/C you should call g_thread_init and gdk_threads_init before
> gtk_init. Than gdk_threads_enter before gtk_init and gdk_threads_leave
> after gtk_main. This enter/leave part is not handled correctly by the
> Ruby Gtk.init. In Gtk+/C enter/leave should be called inside any other
> real-thread before/after calling any gdk function.
But you've not success to work moztest-unlock.c well under this
policy, have you?
we need to discuss not "How to manage native-thread", but "How to work
well GTK components with Ruby thread".
> In Gtk+/Ruby with Ruby-Threads there are no real threads (as pointed out
> by Vincent: "The threads in Ruby NEVER create a native thread.") so
> calling gdk_threads_init should be pointless. On the other side if you
> look at the http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html
> and the *gtk-thread.c* in particular it should be clear that enter/leave
> must be called before/after gtk_main.
The API document says,
"You must call g_thread_init() and gdk_threads_init() before executing
any other GTK+ or GDK functions in a threaded GTK+ program"
Why do you think it's only for GThread?
On the ruby-side, actually it works on threads.
Though GTK+ doesn't know the functions are called from thread or not.
You need to note the documents of GTK+ side covers gthread only.
> I don't know if it is possible to create native-threads in ruby so i
> don't know if enter/leave could be useful at all. (Perhaps it could be
> useful for a timer callback function or so).
At least now, I have to say, NO.
> I don't know, but i've read calling gdk_threads_init can even slow down
> Thank you.
> PS: After some investigation i decided to submit a bug to mozilla
> https://bugzilla.mozilla.org/show_bug.cgi?id=283300 but even if this
> could be solved by gtkmozembed i think threads should be initialized
> only when needed.
So, you say "all of scripts which use Thread should be changed.", right?
I want to discuss what is the beautiful way in Ruby.
IMO, we don't have speed problem if gdk_threads_init is called, because
already it's been called for a long time in init.c.
Any other comments?
.:% Masao Mutoh<mutoh@...>