By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,507 Members | 935 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,507 IT Pros & Developers. It's quick & easy.

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

P: n/a
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?

Jul 19 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"fooooo" <ph*****@yahoo.com> 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.
Jul 19 '05 #2

P: n/a
"fooooo" <ph*****@yahoo.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
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
Jul 19 '05 #3

P: n/a
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

Jul 19 '05 #4

P: n/a
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?

Jul 19 '05 #5

P: n/a
"fooooo" <ph*****@yahoo.com> 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.
Jul 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.