"Conklin, Jason" <JasonC@gentex.com> writes:
I am going to add some more features and I am wondering if it would be more
efficient / stable to rewrite it using the OnIdle() route. I have the
terminal selected as an option off the menu right now, but if I deselect it,
the program crashes when it closes the window. If you exit the app it shuts
down fine though. I also have occasional problems with the ports locking
up..(Could be windoze)
If you're not already, you should probably make sure that your
internal threads have fully shut down before you exit the main
(presumably your GUI) thread. Otherwise, you might have one of those
internal threads try to post an event to a window (or in any other way
trigger something that involves a GUI element) after it has been
destroyed, and that can lead to a GPF.
As an example - here's my EVT_CLOSE handler for an application of mine
that is threaded, and may have two threads (in this code self.network,
and self.process) live at any point in time in addition to the GUI
thread. When shutting down, I first notify those threads to terminate,
wait for them to exit, and the finally destroy the window.
def OnCloseWindow(self, event):
self.network.exit()
self.network.join()
if self.process:
self.process.exit()
self.process.join()
self.Destroy()
As to writing an application with threading versus other methods (such
as the Idle handler, or code that periodically yields), I think that
often comes down to a question of what the tasks are that you need to
do, and any inherited requirements from external modules that code may
have.
If you have an ongoing background process that is fairly easy to
segment into stages (or has a continuous small amount of activity)
then it's probably pretty well suited to the idle approach. But if
you have an activity that is best designed/written as a synchronous
series of operations and/or depends on modules that may block outside
of your control, then I think a thread more appropriate. For some
processes, the event driven nature of the GUI thread (including the
idle processing) may complicate the algorithm of the processing you
want to do in the background - both from an implementation as well as
a source readability perspective.
The amount of GUI involvement for the task is also relevant - since
you want a single thread handling GUI duties, spending a lot of time
posting events from a thread to trigger GUI operations may be
counter-productive. In such a case, trying to get at least the GUI
aspect of your operation within the main thread is probably a good
idea. Conversely, if you have a task being run simultaneously but
which only updates the GUI for periodic status and/or general status,
it might be cleaner in the code to run as an independent thread since
the different control paths are more evident.
If you're not experienced in multi-thread programming, then multiple
threads are more prone to "gotchas" than the other approaches,
particularly if there is any data elements shared between the
threads.
All of which is to say - it depends 
But perhaps this can give you
a few elements to think about in terms of classifying your own processing.
ยทยทยท
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db3l@fitlinxx.com /
> FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/