I will send in a bug report to the GTK guys about this, so they can fix
it. I would expect that the bug falls under the same category as the
other threading related ones found earlier on the list.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On 19 Sep 1999, Andreas Degert wrote:
> claude <[EMAIL PROTECTED]> writes:
>
> > With pygtk-0.6.2 the following script freezes pygtk
> [...]
> > def input_funct1(fp,condition):
> > global inputf
>
> threads_enter()
>
> > lut = fp.readline()
> > fp.close
> > input_remove(inputf)
> > message(['Message',"Message Hello"])
>
> threads_leave()
>
> Does your program work when you add those 2 statements? We had a
> discussion about (i think) a similar problem on this list some time
> ago.
>
> In my understanding, the problem seems to be the strange way gtk is
> made thread-safe, and the way pygtk is handling this. I'll try to
> explain how i understand it.
>
> In a multithreaded gtk-program, one step is to initialize the
> threading-support of gtk (g_thread_init()). Then, when calling gtk
> code, it has to be braced with gdk_threads_enter/leave:
>
> gdk_threads_enter();
> gtk_main();
> gdk_threads_leave();
>
> ..._enter() grabs a semaphore, and ..._leave() releases it. In
> gtk_main(), the semaphore is released for most of the event handling,
> and sometimes grabbed in the widged code to secure critical sections.
>
> Normally, you only call g_thread_init() when you have a threaded
> program, so in a single-threaded program you don't have this coding-
> (and runtime-) overhead. In a multi-threaded program, you have to work
> to make it thread-safe anyhow, so these extra calls are not a big
> deal.
>
> In pygtk, g_thread_init() is called always when thread support is
> compiled in, which is what most distributions are doing now. Now,
> semaphores are used by gtk, but in a single-threaded python program
> the calls won't normally be braced by enter/leave like shown
> above. This seems to work most times, though in gtk_main() the
> semaphore is released without being held, and on exit its held (though
> it was not on entry).
>
> When you use a modal window in a callback function triggered by
> input_add, gtk_main() is called (recursively) and holds the semaphore
> on exit (when you click on the cancel button of the message window),
> but we are still in the event loop of the outer gtk_main, where the
> semaphore shouldn't be held. Now on the next occasion when someone
> tries to grab the semaphore, the program freezes.
>
> I hope James is listening... I think the gtk threading shouldn't be
> initialized unconditionally in pygtk. One possibility would be to wrap
> it in a python function, so threading would have to be initialized
> explicitely when needed. Maybe this solution is a problem for existing
> code. Another idea would be to initialize it on the first call to
> threads_enter().
>
> Another idea would be to brace calls to gtk_main with enter/leave in
> gtkmodule.c (I think there are 2 other gtk functions which should be
> handled similarly). The pygtk-program would then still be responsible
> to call enter/leave for direct calls into gtk from other threads, and
> maybe its not as obvious then because one didn't use the semaphore
> explicitly in the main thread.
>
> IMHO either way would be better than to fiddle with locking functions
> in a single-threaded program to prevent a deadlock.
>
> ciao
> Andreas
> To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
>
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
