[pygtk] Threading

dave 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.


    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"
        elif command=="do_listener_shell":
            #print "doing a listener shell"

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"""
        if listenport==0:
        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.listen(300) #listen for activity.
    def append(self,command,args):
        Append can be called by any thread
        #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.
        #wakey wakey!
        #print "Connecting to port %d"%self.listenport
            #ignore timeouts

    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.
        for i in 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
>>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 mailing list