wxPython and threads again

[Peter Hansen]

David E. Konerding DSD staff wrote:
> Further, calling wx from a thread other than the one running the event 
 > loop is deep voodoo and should typically be avoided.

"Typically"?  Let's just say "always" and maybe use the phrase "certain 
to corrupt wx and crash the app" instead of "deep voodoo". :-)  At least 
that way the OP won't waste time experimenting...

> You need another way to pass completion information between the downloader
> thread and the main thread; the simplest way is to define a custom wx
> Event, and wxPostEvent from the downloader thread when it completes (
> and when the gauge should be updated).  wxPostEvent is safe to call from non-eventloop threads.
> The main thread's wx event loop just spins, properly updating all other
> parts of the GUI, and receiving events from the downloader thread.

Even simpler for some purposes is wx.CallAfter(), which provides the 
asynchronous performance of wxPostEvent with the "beautifully general" 
approach of passing callables through a Queue which Bryan Olson 
described in his post.  (That is, you don't need to do polling with a 
non-blocking get() on the Queue this way.)

-Peter