Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to safely terminate thread in DLL when freeing it up?
579 views
Skip to first unread message
Richard Musil
Jun 14, 2000, 3:00:00 AM6/14/00
to
Hello,
I write DLL module that is supposed to be injected into another process
(either using global hook or AppInit_DLLs key). In DllMain when called with
DLL_PROCESS_ATTACH I create the thread. This thread is according to MS
scheduled due to synchronization reasons after the DllMain is finished. I
would like to safely terminate this thread before this module is unmapped
from process memory space.
First approach I took was using simple schema:
In DllMain when DLL_PROCESS_DETACH occur, signal to the before mentioned
thread to terminate and wait for its termination (using
WaitForSingleObject). However I always get deadlocked (or it seemed so) in
this wait function. MS wrote in MSDN that only one thread can run
simultaneously in DllMain, and since main thread is in there waiting, the
thread that is waited for cannot reenter the DllMain and therefore cannot
terminate itself. It sounds logical if to full thread termination also
corresponding DllMain with DLL_THREAD_DETACH processing is needed.
So I used DisableLibraryThreadCalls to skip all this thread attach/detach
hassle, neverthless I am still deadlocked in wait. It seems like there is no
chance to get the thread signaled before leaving the DllMain in main thread.
I also tried to use the second DLL that only loads up the first one DLL in
"process attach" and "safely" terminates the before mentioned thread and
frees up the first one DLL in "process detach". For this module I have also
disabled attach/detach thread calls, but it leads to the same situation. I
do not know how to verify that my standalone thread is waiting until the
corresponding DllMain routines are free to enter, and simultaneously main
thread is in DllMain waiting for the thread to terminate :-(
What can I do is to not wait for the thread object but instead setup en
event, but I take it as a last chance since it is far away from robust
design and can lead to thread termination on system behalf.
Is there a way to solve it, or did I overlooked anything? Any comments are
highly appreciated.
I write DLL module that is supposed to be injected into another process
(either using global hook or AppInit_DLLs key). In DllMain when called with
DLL_PROCESS_ATTACH I create the thread. This thread is according to MS
scheduled due to synchronization reasons after the DllMain is finished. I
would like to safely terminate this thread before this module is unmapped
from process memory space.
First approach I took was using simple schema:
In DllMain when DLL_PROCESS_DETACH occur, signal to the before mentioned
thread to terminate and wait for its termination (using
WaitForSingleObject). However I always get deadlocked (or it seemed so) in
this wait function. MS wrote in MSDN that only one thread can run
simultaneously in DllMain, and since main thread is in there waiting, the
thread that is waited for cannot reenter the DllMain and therefore cannot
terminate itself. It sounds logical if to full thread termination also
corresponding DllMain with DLL_THREAD_DETACH processing is needed.
So I used DisableLibraryThreadCalls to skip all this thread attach/detach
hassle, neverthless I am still deadlocked in wait. It seems like there is no
chance to get the thread signaled before leaving the DllMain in main thread.
I also tried to use the second DLL that only loads up the first one DLL in
"process attach" and "safely" terminates the before mentioned thread and
frees up the first one DLL in "process detach". For this module I have also
disabled attach/detach thread calls, but it leads to the same situation. I
do not know how to verify that my standalone thread is waiting until the
corresponding DllMain routines are free to enter, and simultaneously main
thread is in DllMain waiting for the thread to terminate :-(
What can I do is to not wait for the thread object but instead setup en
event, but I take it as a last chance since it is far away from robust
design and can lead to thread termination on system behalf.
Is there a way to solve it, or did I overlooked anything? Any comments are
highly appreciated.
--
Richard Musil
P.S. Since I have no control over the DllMain with process detach is called
I cannot simply terminate the standalone thread "just before it should
happen".
keithmo
Jun 14, 2000, 3:00:00 AM6/14/00
to
1. Use GetModuleFileName() and LoadLibrary() to add an "artificial"
reference to the DLL just before you create the worker thread.
2. Use FreeLibraryAndExitThread() within the worker thread to remove the
artificial reference & exit.
reference to the DLL just before you create the worker thread.
2. Use FreeLibraryAndExitThread() within the worker thread to remove the
artificial reference & exit.
KM
"Richard Musil" <richard.musil@b_i_gfoot.com> wrote in message
news:uT7Dvyj1$GA.252@cppssbbsa04...
Richard Musil
Jun 15, 2000, 3:00:00 AM6/15/00
to
Thanks a lot,
I am going to give it a try just now :-)
I am going to give it a try just now :-)
--
Richard Musil
Ron Darziv
Jun 16, 2000, 3:00:00 AM6/16/00
to
There is excellent cover of this problem and a good solution in Jeff
Richters new book:
Programming Applications for Microsoft Windows.
Ron.
>
>
0 new messages