I've got a several-second-long task that I put into a separate thread.
When I run it, though, it seems to starve the main thread -- if I drag
a dialog over the main window while it is running, for instance, the
screen doesn't redraw.
If I add a "time.sleep(.0001)" in my worker thread the UI becomes
responsive again. This leads me to believe that this secondary thread
is causing the main thread to be starved. Is that a correct
conclusion?
I'm relatively new to threading with wxPython, but I'm not doing
anything particularly complicated. My worker thread uses a generator
to get a list of data objects, and it iterates over those data
objects. Anytime my worker needs to do GUI work (eg: add an item to a
ListCtrl) it does it via wx.CallAfter so it is handled in the main
thread.
I've got a several-second-long task that I put into a separate thread.
When I run it, though, it seems to starve the main thread -- if I drag
a dialog over the main window while it is running, for instance, the
screen doesn't redraw.
If I add a "time.sleep(.0001)" in my worker thread the UI becomes
responsive again. This leads me to believe that this secondary thread
is causing the main thread to be starved. Is that a correct
conclusion?
I'm relatively new to threading with wxPython, but I'm not doing
anything particularly complicated. My worker thread uses a generator
to get a list of data objects, and it iterates over those data
objects. Anytime my worker needs to do GUI work (eg: add an item to a
ListCtrl) it does it via wx.CallAfter so it is handled in the main
thread.
Yes this is very much possible (regardless of programming language).
Often calling sleep(0) will suffice to signal the os to give up a time
slice to another thread.
You could also be locking up the ui if your making lots of update
calls from the background thread(s) as there will be some additional
overhead for the event processing in addition to the ui calls your
making.
Cody
···
On Mon, May 17, 2010 at 1:31 PM, Bryan Oakley <bryan.oakley@gmail.com> wrote: