Multiple threads in a GUI app (wxPython), communication between worker thread and app?

[fooooo]

This is a network app, written in wxPython and the socket module. This
is what I want to happen:

GUI app starts. User clicks a button to 'start' the work of the app.
When start is pressed, a new thread is spawned (threading module) and
this thread starts listening for data on a socket. When someone
connects, a new thread is spawned, It needs to do I/O on that socket
and open a GUI window so the user can communicate with the client
(socket) that just connected. Any further data that comes in on that
socket should be redirected to the newly opened GUI window. Any more
connection attempts will open a new GUI window and the same cycle
repeats.

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?

 

[Paul Rubin]

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.

 

[John Perks and Sarah Mount]

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

 

[M.E.Farmer]

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

 

[fooooo]

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?

 

[Paul Rubin]

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.