Hello wxpythons,
Ive got a python program using wx, which uses a decorator function to spawn
long-running methods into subthreads. In each long-running subthread, I
acquire a reentrant global lock and MutexGuiEnter() and when the thread is
finished executing, I release the lock and MutexGuiLeave().
The subthread does update the main GUI, specifically it adds text as it
progresses to a wxTextCtrl field (thus the reason for the
MutexGuiEnter/Leave-part, since this alllows subthreads to access the
non-threaded wx library according to doc)
The program works as intended on Mac OSX 10.4 using wx 2.8. Text is added
on-the-fly to the wxTextCtrl as the thread progresses. But on GNU/Linux
Kubuntu Edgy using python-wxgtk2.6 version 2.6.3.2.1.5 and gcc 4.1.2, the
wxTextCtrl is not updated on the fly.
Granted the GUI does not "hang" in GNU/Linux when the thread is spawned, like
it did previous to the threading implementation. But it seems the text only
appears when the thread is finished processing and returns to the main loop.
So Im really curious how this difference can manifest itself, and more
importantly - how do I "fix" it for GNU/Linux?
Thanks for any feedback!
Regards,
Frank Aune
Don't make direct calls from a secondary thread, even if you aquire
the GUI lock. Use wx.CallAfter to execute any UI code from the main
thread.
···
On 1/19/07, Frank Aune <frank.aune@broadpark.no> wrote:
Hello wxpythons,
Ive got a python program using wx, which uses a decorator function to spawn
long-running methods into subthreads. In each long-running subthread, I
acquire a reentrant global lock and MutexGuiEnter() and when the thread is
finished executing, I release the lock and MutexGuiLeave().
The subthread does update the main GUI, specifically it adds text as it
progresses to a wxTextCtrl field (thus the reason for the
MutexGuiEnter/Leave-part, since this alllows subthreads to access the
non-threaded wx library according to doc)
The program works as intended on Mac OSX 10.4 using wx 2.8. Text is added
on-the-fly to the wxTextCtrl as the thread progresses. But on GNU/Linux
Kubuntu Edgy using python-wxgtk2.6 version 2.6.3.2.1.5 and gcc 4.1.2, the
wxTextCtrl is not updated on the fly.
Granted the GUI does not "hang" in GNU/Linux when the thread is spawned, like
it did previous to the threading implementation. But it seems the text only
appears when the thread is finished processing and returns to the main loop.
So Im really curious how this difference can manifest itself, and more
importantly - how do I "fix" it for GNU/Linux?
Thanks for any feedback!
Regards,
Frank Aune
Depending on the platform, drawing can happen at various times. In some,
it only happens when the main event loop is able to process events.
Since you have acquired the GUI lock, the GUI thread cannot process any
events, so may not redraw. What you should do is to acquire and release
the GUI lock just to handle the updates, and keep it unlocked when you
don't need to update. Something like this...
while <something>:
x = <some long-running operation>
wx.MutexGuiEnter()
try:
<update the GUI>
finally:
wx.MutexGuiLeave()
This should allow the Gui to redraw as necessary. You could also
replace the above with something like the following (which Chris Mellon
suggested)...
while <something>:
x = <some long-running operation>
wx.CallAfter(sometextctrl.AppendText, x)
Which will handle all of the locking, unlocking, etc., automatically.
- Josiah
···
Frank Aune <frank.aune@broadpark.no> wrote:
Hello wxpythons,
Ive got a python program using wx, which uses a decorator function to spawn
long-running methods into subthreads. In each long-running subthread, I
acquire a reentrant global lock and MutexGuiEnter() and when the thread is
finished executing, I release the lock and MutexGuiLeave().
The subthread does update the main GUI, specifically it adds text as it
progresses to a wxTextCtrl field (thus the reason for the
MutexGuiEnter/Leave-part, since this alllows subthreads to access the
non-threaded wx library according to doc)
The program works as intended on Mac OSX 10.4 using wx 2.8. Text is added
on-the-fly to the wxTextCtrl as the thread progresses. But on GNU/Linux
Kubuntu Edgy using python-wxgtk2.6 version 2.6.3.2.1.5 and gcc 4.1.2, the
wxTextCtrl is not updated on the fly.
Granted the GUI does not "hang" in GNU/Linux when the thread is spawned, like
it did previous to the threading implementation. But it seems the text only
appears when the thread is finished processing and returns to the main loop.
So Im really curious how this difference can manifest itself, and more
importantly - how do I "fix" it for GNU/Linux?