Jeff Bowden wrote:
Antoon Pardon wrote:
On Wed, Feb 04, 2004 at 09:54:11PM -0800, Jeff Bowden 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?
I'm not sure, but it feels wrong to me to try to develop a portable system based on signals...I'm planning on opening a local socket, and then trapping any action on that socket with gtk.input_add() and having it clear a queue full of actions in the GUI thread. I'll probably be releasing this code sometime next week and, if there are no major objectsion, adding it to the faq. I'd also like to track down the thread synchronization issue in the destructor of gtk.glade and/or the add_signals_dict call that is expressing itself on Windows. I'd like to be able to recompile a dropline, if at all possible.
-dave
I believe that it is safe to call g_idle_add from a different thread, even without acquiring the GDK thread lock first. This makes it a simple and obvious way to pass information and events back to the main thread.
Note that you need to call gdk_threads_enter/gdk_threads_leave in the idle function if you are doing any GUI stuff in it.
-- Tim Evans Applied Research Associates NZ http://www.aranz.com/ _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
