I seriously recommend doing all your thread work in your main thread, and then having that thread clear a queue of events. Then you fill the queue with your other threads. It sounds complex, but it's really the simplest way in the long run.

This is also good because it isolates your gui code into one file.

I know everyone has their own way, but this way works great for CANVAS, meaning it works on at least a medium-sized project that's cross platform (Linux/Win32). I noticed that every time I deviated from doing it this way, I ran into trouble. Some things, like gtk.glade.xml() simply don't work from other threads in certain versions of pyGTK.

We actually offer a version of CANVAS for free (under NDA) which could help you. If there's stuff you want to steal from CANVAS to do threading, we're happy to LGPL/PythonLicense it...

-dave


Thomas Mills Hinkle wrote:

Hi all. I've been trying to track down some bad threading behavior in
my pygtk app (Gourmet Recipe Manager) for a few days. What I'm ending up
with is a freeze of my application when a threaded process is running (I
have import and export processes run in separate threads and update a
progress bar). Anyway, I've traced the problem to the following code:

def cleanup_pause (self, thread):
gtk.threads_enter()
self.pauseButton.disconnect(self.pause_connection) self.pauseButton.set_active(False)
self.pauseButton.hide()
gtk.threads_leave()


What this code does is hides a "pause" and a "stop" button that appear
next to the progress bar when the import/export is in progress (these
are CPU intensive processes that can go on and on, so, as per the GNOME
HIG[1] I allow the user to interrupt or stop them.)

This code will hang at the disconnect call. Usually, it hangs on the
second or third import/export that calls the code. It has never hung the
first time (in other words, it executes all code perfectly). My app
doesn't allow concurrent import/export calls, so AFAIK, the behavior
shouldn't be any different on the second or third export or import than
it is on the first. But it is.

My planned workaround is to rework how I handle the pause and stop
buttons -- rather than reconnecting them to each thread's pause action
when it starts, I'll connect them to a handler and have that function
figure out which thread is running and how to pause/stop it.  However,
before I implemented the workaround, I wanted to document the problem
here and see if anyone could explain why disconnecting would cause a
problem. It seems to have to do with threading -- I made a simple test
app that reconnects and disconnects a button without issue.

Tom

Notes
-------
1.http://developer.gnome.org/projects/gup/hig/1.0/feedback.html#allowing
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/



_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Reply via email to