John K Luebs wrote:
On Wed, Feb 04, 2004 at 01:10:27PM -0800, Jeff Bowden wrote:
For general threading this is true, but most GUI threading can be reduced to background "producer" threads which feed results to a designated GUI "consumer" thread via a python Queue object. This sort of architecture is often easier to understand and debug than ad-hoc threading.
This is a good point, and I agree completely. I just wanted to point out
that even if you lock correctly and have a program that is correct for the X11 port that you are not guaranteed that it works for the Windows port due to fundamental limitations in the Win32
windows/message queue design. The general work around given above is a
cure that is probably worse than the disease (which is why no one is
champing at the bit to implement it), because arguably well designed applications shouldn't run into the problem in the first place.
--jkl
I'm confused. How should I design my pyGTK application to avoid this issue?
The basic idea is this: You have some need in your pygtk app for some code to run asynchronously in a seperate thread (the "background task"). In order for it to be useful, you need two way communication between the background task and your main thread which handles all the GUI stuff. e.g.
class BackgroundTask(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
self.in_q = Queue.Queue()
self.out_q = Queue.Queue()
self.die = False
# ... def run(self):
while not self.die:
args = self.in_q.get()
result = self.do_stuff(*args)
self.out_q.put(result)And then in your gtk idle function a fragment like this:
if not background_task.out_q.empty():
result = background_task.out_q.get()# do stuff with the result...
And then in whatever part of your program that initiates background tasks something like
background_task.in_q.put(args)
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
