-dave
def handle_gui_queue(self,command,args):
"""
Callback the gui_queue uses whenever it recieves a command for us.
command is a string
args is a list of arguments for the command
"""
#print "handle_gui_queue"
if command=="set_label":
#print "setting label"
obj=args[0]
label=args[1]
obj.set_label(label)
elif command=="do_listener_shell":
lst=args[0]
#print "doing a listener shell"
self.do_listener_shell(listener=lst)
#gui_queue.py
class gui_queue:
"""wakes up the gui thread which then clears our queue"""
def __init__(self,gui,listenport=0):
"""If listenport is 0, we create a random port to listen on"""
self.mylock=RLock()
self.myqueue=[]
if listenport==0:
self.listenport=random.randint(1025,10000)
else:
self.listenport=listenport
print "Local GUI Queue listening on port %s"%self.listenport
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(("", self.listenport)) self.listensocket=s
self.listensocket.listen(300) #listen for activity.
#time.sleep(15)
self.gui=gui
return
def append(self,command,args):
"""
Append can be called by any thread
"""
self.mylock.acquire()
self.myqueue.append((command,args))
#this won't work on a host with a ZoneAlarm firewall or no internet connectivity...
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
#small timeout will wake up the gui thread, but not
#cause painful pauses if we are already in the gui thread.
#important to note that we use timeoutsocket and it
#is already loaded.
s.set_timeout(0.01)
#wakey wakey!
#print "Connecting to port %d"%self.listenport
try:
s=s.connect(("localhost",self.listenport))
except:
#ignore timeouts
pass
self.mylock.release()
return
def clearqueue(self):
"""
Clearqueue is only called by the main GUI thread
Don't forget to return 1
"""
#print "Clearing queue"
#clear this...TODO: add select call here.
newconn,addr=self.listensocket.accept()
for i in self.myqueue:
(command,args)=i
self.gui.handle_gui_queue(command,args)
self.myqueue=[]
return 1
Tiago Cogumbreiro wrote:
On Wed, 2004-06-23 at 08:30, Antoon Pardon wrote:
On Tue, Jun 22, 2004 at 07:27:33PM -0400, dave wrote:
I personally believe the best way is to have a socket or pipe as a trigger, and do all your gui stuff in one main thread, triggered by a socket connection. Immunity does this on both win32 and linux to avoid all the problems with threading entirely. If I get some time, I'll write a quick paper on it and give some good examples.Well I use idle_add if I want all gui stuff to be done in the main
-dave
thread.
What I would prefer is somekind of gtk.Queue class that would work like the queues from the Queue module but for which it would be possible to register a handler with queue_add_watch just like you can register a handler for io with io_add_watch.
Now I more or less simulate this by thinking of the idle_add like a Queue.put() and the call of the registered function like a Queue.get().
BTW, In trying to understand how to work with threads, I have written number of programs that all do the same but which are organised differently in how the threads cooperate. (They look a bit like the wxPython thread demo)
Allthough they aren't finished yet, they could be usefull
as demo's. Do demo programs need to follow some guide lines?
Does someone has some place to put them? Can I put them on
the list? Maybe someone else can give them a look over
since I consider my self a gtk-newbee, so maybe somethings
I do could be done better?
I for one would like to see them :) A threading tutorial is always nice. Making demos out of the most common concurrent patterns would also be interesting.
_______________________________________________
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/
