On Mon, Feb 09, 2004 at 12:47:58PM +0100, Antoon Pardon wrote: > On Sun, Feb 08, 2004 at 11:20:49PM -0500, John K Luebs wrote: > > On Sun, Feb 08, 2004 at 12:59:44PM -0800, Jeff Bowden wrote: > > > Antoon Pardon wrote: > > > > > > > >My idea to handle this would be to create a new signal. Have a handler > > > >for this signal in the gui thread and let the background task emit this > > > >signal. Would this be workable? On Windows? > > > > > > > > > > > > > > > > > > I'm not sure if that even works on Linux. I haven't traced down the > > > code path but it wouldn't surprise me if emit ends up executing > > > synchronous calls to the connected signal handlers. Is this documented > > > somewhere? Am I wrong? > > > > You're correct, the signal handler will end up being handled in the > > thread that calls emitted. Signals are not queued asynchronously or > > anything. I'm not sure where this is documented but it goes along > > with the overall thread agnostic design of GTK+. > > But FAQ 20.1 says: > > Signal callbacks will be done in the main thread.
The FAQ entry is wrong. Based on the heading of the entry one might believe that what is meant is that signal callbacks *should* be done in the main thread. But even if we assume this, it is still not correct, because GTK signal handlers do not need a threads_enter/threads_leave pair because the lock should have already been acquired by whatever is emitting the signal. Interestingly, if we substitute "Timeout, input, and idle handlers" in place of "Signal callbacks" the statement becomes correct. As long as you only call mainloop in the main thread, those glib handlers will only be called in the main thread, additionally, those handlers must acquire the gtk lock if they are going to call gtk. --jkl > _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
