Re: Multiple threads in a GUI app (wxPython), communication between worker thread and app?
Jp Calderone <[EMAIL PROTECTED]> writes: > >Secondly, I don't know about wxPython, but in tkinter you have to > >resort to a kludge in order for the gui thread to handle gui events > >and also notice stuff on a queue. There's a tkinter command to run > >some function after a specified time (say 50 msec). So you'd set that > >timeout to check the queue and restart the timer, which means the gui > >would check 20x a second for updates from the worker threads. When it > >got such an update, it would create a new window or whatever. > > You can do better than this. Tkinter has an after_idle function, > which lets you post an event to the Tkinter thread _immediately_. > This is basically the Queue "put" operation. I don't understand how this is supposed to work. Can you explain a little further? As far as I can tell, it's not documented as safe to call w.after_idle from another thread. Is it actually safe according to how the code is written? Otherwise, the only way I can see is to use a queue (or other synchronization object) and let the tkinter thread check the queue periodically itself. > > Python thread support seems to have been something of an > > afterthought and there's a lot of weirdness like this to deal with. > I'm not sure what you see as weird about this. Having to deal with this timeout stuff instead of having a documented thread-safe way to add events to a tkinter event queue. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple threads in a GUI app (wxPython), communication between worker thread and app?
"fo" <[EMAIL PROTECTED]> writes: > Thanks for the replies. I have a Queue object in the main GUI thread, > this gets passed to all the worker threads and they add items to it. > This is all well and good, but what is a good way to get the GUI thread > to send items back to the worker threads? Use another Queue. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple threads in a GUI app (wxPython), communication between worker thread and app?
Thanks for the replies. I have a Queue object in the main GUI thread, this gets passed to all the worker threads and they add items to it. This is all well and good, but what is a good way to get the GUI thread to send items back to the worker threads? -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple threads in a GUI app (wxPython), communication between worker thread and app?
Look inthe demo that comes with wxPython it is in tree process and events -> threads . There is a nice demo of PostEvent(). Another way would be to use Queues as others have mention . You can create a new frame and have it call the queue for data. M.E.Farmer -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple threads in a GUI app (wxPython), communication between worker thread and app?
"fo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > This is a network app, written in wxPython and the socket module. This > is what I want to happen: I'm not sure if this will help you, but it solved what was, for me, a more general problem: not (normally) being able to issue wxPython calls outside the GUI thread. I came up with a general-purpose thread-switcher, which, given a callable, would on invocation: queue itself up on the GUI event queue call its callable in the GUI thread (allowing arbitrary wxPython calls) pass its result back to the calling thread (or re-raise any exception there). Instead of having a dedicated queue, it uses one already in place. Because all calls using it are serialized, it had the beneficial side-effect (for me, anyway)of avoiding certain concurrency issues. (The calls to my locks module, CheckPause() and CheckCancel(), were there so the user could suspend, resume, and cancel worker threads at will, which the Python threading module does not naturally support(my locks module held some state that could be set via the GUI.) If you have no need of that, delete those lines and everything should still work (they were a late addition). import wx, threading, types import locks # my code, see remark above #- # decorator used to call a method (or other callable) # from the wxPython main thread (with appropriate switching) #-- class wxThreadSwitch(object): def __init__(self, callable): object.__init__(self) self.callable = callable def __get__(self, inst, owner=None): c = self.callable # if c is a descriptor then wrap it around # the instance as would have happened normally if not isinstance(c, types.InstanceType): try: get = c.__get__ args = [inst] if owner is not None: args.append(owner) return wxThreadSwitch(get(*args)) except AttributeError: pass # if we get here, then not a descriptor, # so return self unchanged return self def __call__(self, *args, **kwargs): if wx.Thread_IsMain(): return self.callable(*args, **kwargs) locks.CheckPause() c = self.__wxThreadCall(self.callable) wx.CallAfter(c, *args, **kwargs) return c.Result() class __wxThreadCall(object): def __init__(self, callable): assert not wx.Thread_IsMain() object.__init__(self) self.callable = callable self.result = None self.exc_info = None self.event = threading.Event() def __call__(self, *args, **kwargs): try: try: assert wx.Thread_IsMain() assert not self.event.isSet() locks.CheckCancel() self.result = self.callable(*args, **kwargs) except: self.exc_info = sys.exc_info() finally: self.event.set() def Result(self): self.event.wait() if self.exc_info: type, value, traceback = self.exc_info raise type, value, traceback return self.result A usage example would be to decorate a function or method with it: class Something: @wxThreadSwitch def someGUICallOrOther(): Here the method call would run via the wxThreadSwitch decorator which would do any necessary thread switching. Hope this helps John -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple threads in a GUI app (wxPython), communication between worker thread and app?
On 01 May 2005 10:09:56 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: "fo" <[EMAIL PROTECTED]> writes: How would I get the worker thread to open a GUI window in the main GUI thread? After that GUI window is open, how can I send and recv messages from/to the GUI window? First of all the favorite Pythonic way to communicate between threads is with synchronized queues--see the Queue module. Have the worker thread put stuff on a queue and have the main GUI thread read from it. Yea, this is a good way. Also, it is essentially what you describe below :) The Queues are just created and drained by the GUI library instead of the user's application code. Secondly, I don't know about wxPython, but in tkinter you have to resort to a kludge in order for the gui thread to handle gui events and also notice stuff on a queue. There's a tkinter command to run some function after a specified time (say 50 msec). So you'd set that timeout to check the queue and restart the timer, which means the gui would check 20x a second for updates from the worker threads. When it got such an update, it would create a new window or whatever. You can do better than this. Tkinter has an after_idle function, which lets you post an event to the Tkinter thread _immediately_. This is basically the Queue "put" operation. It could be that wxPython has a cleaner way of doing this, or you might have to do something similar. It has essentially the same thing, PostEvent(). Python thread support seems to have been something of an afterthought and there's a lot of weirdness like this to deal with. I'm not sure what you see as weird about this. Jp -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple threads in a GUI app (wxPython), communication between worker thread and app?
"fo" <[EMAIL PROTECTED]> writes: > How would I get the worker thread to open a GUI window in the main GUI > thread? After that GUI window is open, how can I send and recv messages > from/to the GUI window? First of all the favorite Pythonic way to communicate between threads is with synchronized queues--see the Queue module. Have the worker thread put stuff on a queue and have the main GUI thread read from it. Secondly, I don't know about wxPython, but in tkinter you have to resort to a kludge in order for the gui thread to handle gui events and also notice stuff on a queue. There's a tkinter command to run some function after a specified time (say 50 msec). So you'd set that timeout to check the queue and restart the timer, which means the gui would check 20x a second for updates from the worker threads. When it got such an update, it would create a new window or whatever. It could be that wxPython has a cleaner way of doing this, or you might have to do something similar. Python thread support seems to have been something of an afterthought and there's a lot of weirdness like this to deal with. -- http://mail.python.org/mailman/listinfo/python-list
