Incognito
2011-05-01 08:07:34 UTC
Okay, unless you couldn't tell by the subject, my problem is somewhat of a
complicated one. I have a DLL that acts as a TCP client using Asio.
Everything works great while the program is running, but unfortunately,
sometimes the program hangs upon exit. I've found that this only happens if
the server does not close the socket before the program exits. If the socket
is still open when the user tries to exit, the program hangs.
Upon further inspection, the program _only_ hangs if the io_service contains
a handler to async_read (or async_read_some). I don't know why this is the
case, but it happens every time.
Here's a very small portion of my code:
void run()
{
boost::this_thread::sleep(boost::posix_time::seconds(1));
// Additional code here to give io_service some work to do
io_service.run();
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
boost::thread thread(run);
break;
}
}
Some remarks:
Yes, I know that creating threads in DllMain is bad form. Yes, I know that
synchronizing threads in DllMain is hard or nearly impossible. However, I
don't have access to the source of the executable, so my only choice is to
create a separate thread when the DLL loads so that the io_service does not
block the main thread.
I've tried doing a number of things under DLL_PROCESS_DETACH. I've tried
using io_service.stop(), but that does nothing. I've tried putting the
io_service in a scoped_ptr and resetting it, but that causes the io_service
destructor to hang as well. I've tried interrupting and terminating the
thread in every way imaginable, but it seems that I simply can't communicate
with the thread once the process ends.
The only thing that has worked is using ExitThread under DLL_PROCESS_DETACH
if the socket is still open. This has been my workaround for a while, but it
forces the whole program to end immediately, so I don't like it. Surely
there's some way that's more elegant.
If anyone has any suggestions (or any insights at all as to why this only
happens when there is an ongoing asynchronous read operation), please let me
know.
Thanks.
complicated one. I have a DLL that acts as a TCP client using Asio.
Everything works great while the program is running, but unfortunately,
sometimes the program hangs upon exit. I've found that this only happens if
the server does not close the socket before the program exits. If the socket
is still open when the user tries to exit, the program hangs.
Upon further inspection, the program _only_ hangs if the io_service contains
a handler to async_read (or async_read_some). I don't know why this is the
case, but it happens every time.
Here's a very small portion of my code:
void run()
{
boost::this_thread::sleep(boost::posix_time::seconds(1));
// Additional code here to give io_service some work to do
io_service.run();
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
boost::thread thread(run);
break;
}
}
Some remarks:
Yes, I know that creating threads in DllMain is bad form. Yes, I know that
synchronizing threads in DllMain is hard or nearly impossible. However, I
don't have access to the source of the executable, so my only choice is to
create a separate thread when the DLL loads so that the io_service does not
block the main thread.
I've tried doing a number of things under DLL_PROCESS_DETACH. I've tried
using io_service.stop(), but that does nothing. I've tried putting the
io_service in a scoped_ptr and resetting it, but that causes the io_service
destructor to hang as well. I've tried interrupting and terminating the
thread in every way imaginable, but it seems that I simply can't communicate
with the thread once the process ends.
The only thing that has worked is using ExitThread under DLL_PROCESS_DETACH
if the socket is still open. This has been my workaround for a while, but it
forces the whole program to end immediately, so I don't like it. Surely
there's some way that's more elegant.
If anyone has any suggestions (or any insights at all as to why this only
happens when there is an ongoing asynchronous read operation), please let me
know.
Thanks.