Threaded GUI slowing method execution?

Aaron Hoover ahoover at EECS.Berkeley.EDU
Fri Oct 2 22:29:01 CEST 2009

On Oct 2, 2009, at 12:30 PM, Dave Angel wrote:

> (you responded off-list, which isn't the way these mailing lists  
> work.  So I'm pasting your message back to the list, with my  
> response at the end)

Sorry about that - a slip of the "reply" button.

> Actually, I was thinking of the subprocess module (introduced in  
> 2.4).  But the multiprocessing module would be useful if you were  
> porting threading code to a process model.

Previously, I had been using threads, so I just tried moving to  
multiprocessing because it required few changes.

> There are tons of ways to communicate between processes, though you  
> can't do the simple variable sharing that threads can (sometimes)  
> get away with.  I would normally point you to queues, but there a  
> number of possibilities.  And since the one process is running a GUI  
> event loop, you might want to piggyback on the OS capability to post  
> events between processes.  The code might end up OS-dependent, but  
> I'd bet the overhead will be minimal.  What is your target operating  
> system?

My target OS is Mac OS X Leopard. I've decided just to try and trigger  
WX events in the GUI based on data put in one of the queues by the  
processing thread.

> Your numbers in the original message make me nervous;  sending an  
> event between processes (or even threads) every 0.5 millisecond is  
> impossible.  But I think you might have been confusing bytes and  
> packets.

My external hardware is actually sending 2000 packets per second right  
now (but that can also be changed). Each packet currently contains 6  
bytes of data and 6 bytes of overhead. So, 12 bytes per packet * 2000  
packets per second is 24k bytes per second. However, the serial  
processing process should be finding the packet payload data and  
adding to a queue for the GUI to deal with and plot (obviously at a  
much lower framerate) (at an ideal rate of 2KHz).

> There could very well be multiprocess support in wxPython.  I'd  
> check there first, before re-inventing the wheel.  Presumably you  
> know of the wxPython news group, hosted on Google groups?

I actually tried using multiprocess to create a separate process for  
reading the serial data. The process gets passed a TX queue and an RX  
queue in its constructor, then it's supposed to enter an infinite loop  
where it waits for commands on the TX queue and reads data and puts in  
in the RX queue. However, I've discovered for some reason that the  
infinite loop terminates after the first call I make to either of the  
queues. Perhaps this behavior should be expected, but this is my first  
go-round with processes, so I was a little surprised by this result.  
Maybe someone with more multiprocessing experience can give me some  

Maybe I am barking up the wrong tree with Python from a speed  
perspective, but it's just some much faster and more fun to write than  
anything else...


More information about the Python-list mailing list