dave at immunitysec.com
Wed Jun 23 19:52:38 WST 2004
This is some of the code I use...it may not be perfect, but it does work
reliably on win32 and linux.
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 "setting label"
#print "doing a listener shell"
"""wakes up the gui thread which then clears our queue"""
"""If listenport is 0, we create a random port to listen on"""
print "Local GUI Queue listening on port %s"%self.listenport
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
self.listensocket.listen(300) #listen for activity.
Append can be called by any thread
#this won't work on a host with a ZoneAlarm firewall or no
#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.
#print "Connecting to port %d"%self.listenport
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.
for i in self.myqueue:
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
>>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
>pygtk mailing list pygtk at daa.com.au
>Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
More information about the pygtk