[pygtk] Threading

[dave]

This is some of the code I use...it may not be perfect, but it does work 
reliably on win32 and linux.

-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.
>>>
>>>-dave
>>>      
>>>
>>Well I use idle_add if I want all gui stuff to be done in the main
>>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   pygtk at daa.com.au
>http://www.daa.com.au/mailman/listinfo/pygtk
>Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
>  
>