Re: MFC DLL - ExitInstance hang on WaitForSingleObject
On Fri, 1 May 2009 19:17:01 -0700, Erakis
<Erakis@discussions.microsoft.com> wrote:
Hi Doug,
Sorry for "brake point" :)
First of all I want to thank for your great help, this is really appreciated
:)
If I well understand what you said, I cannot create or stop thread in
InitInstance/ExitInstance ? Why MSDN do not talk about that ? Else, what it
is permit to do and not in those two fuction ?
MSDN doesn't talk about a lot of things, and that's especially true when
you look at individual articles as opposed to MSDN as a whole. As I recall,
the application object for an MFC DLL (only "non-extension" MFC DLLs have
application objects) is a global variable, globals in DLLs are constructed
and destructed in DllMain context, and InitInstance/ExitInstance are called
as part of app object construction/destruction. For more on DllMain
restrictions, see the DllMain documentation and search MSDN for "DllMain"
and "loader lock".
See also my last four posts in this thread, where I explain a scenario that
causes deadlock when a thread is created in DllMain:
http://groups.google.com/group/microsoft.public.vc.mfc/browse_frm/thread/7d0576f42150e80d/63906b040cd5e2ff?hl=en#63906b040cd5e2ff
Finally, there are a lot of MS people who write blogs that contain info you
won't find in MSDN, so that's another source to search.
If I make two function in the DLL ; InitLib() and CloseLib()
So the EXE could load the DLL, call InitLib(), create a new Pooler using the
PoolerCreate() function and at close event of the EXE, the EXE should call
CloseLib()
to stop all the running Pooler and free other resource ?
What if the EXE do not call CloseLib() ? It still will produce strange
behavior ? Leak ?
Because this DLL is a library and anyone could use it so I don't want to
introduce any leak in case of bad use. Do I'm stuck with this limitation ?
Yep. I don't see any way to make it fully automatic.
--
Doug Harrison
Visual C++ MVP