On Mon, 1 May 2006 11:08:20 -0600, "Tom Salicos" <TSalicos@Drykilns.net>
"Doug Harrison [MVP]" <email@example.com> wrote in message
On Tue, 18 Apr 2006 08:01:45 GMT, "Jessica Weiner" <firstname.lastname@example.org>
If a thread has a finite lifetime, should we let it finish it self or
we call ExitThread when its work is done?
If it's an MFC thread, it would call AfxEndThread, but it shouldn't even
that. Among other things, local objects won't be destroyed, because the
stack won't be unwound. By far the best way is for the main thread
to return. BTW, pretty much all threads should have "finite lifetimes" for
the reasons given here:
Visual C++ MVP
The above link was 404 for me.
Should be fine now. Thanks for the note.
I am concerned about the statement , "... 'pretty much all threads should
have "finite lifetimes" '. I have an MFC app with a worker thread that
reads A/D values into a buffer and also writes buffered output to discrete
devices. The thread uses a waitable timer to execute every 100 ms. Timing
is not super critical. This runs continuously in a system that never stops,
short of power failures and maintenence shutdowns. The app's main thread
uses the data every few seconds for PID calcs, data logging, etc.
If threads should have finite lifetimes, then how else would you run a
full-time data acquisition function parallel to the main app?
Also, the best example of asyncronous sockets I have found uses CWinThread.
Are these not supposed to live forever?
Without the explanation in the link above, I don't know why a thread
should/must have a finite lifetime. Can somebody point me?
In a nutshell, it's considered good practice to join with all your threads
before exiting main(). This prevents the secondary threads from running
while the main thread is destroying global and local static objects,
shutting down the CRT, etc, which could invalidate resources the secondary
threads are still using. It's also considered good practice for program
initialization to be single-threaded; that is, threads should not be
created before main() is entered. This is especially true for DLLs, which
should never create threads during DLL_PROCESS_ATTACH/DETACH, which also
happen to be when they create their globals and destroy their globals and
local statics, respectively. It's important to realize that the DllMain
restrictions apply to the initialization of DLL globals and the destruction
of DLL globals and local statics.
Visual C++ MVP