Hi,
Am trying to use Casablanca as a dll in another third party exe on Windows 7.
Everything works fine, except when closing the socket and unloading the dll.
My close function is as follows
```
void __stdcall WSDisconnect()
{
auto current_context = task_continuation_context::use_default();
create_task([=]()
{
try
{
m_ws_client.close().then([=](task<void> close_task) {
close_task.get();
});
}
catch (websocket_exception& wex)
{
}
}, current_context);
}
```
The close task closes and returns almost immediately, however the call to above function hangs till timeout ( enforced by the third party exe ).
Is this due to trying to use Casablanca on Windows 7 without WinRT, or something else. Any pointers on the fixing the issue welcome.
Regards
Vivek
Comments: Ok I investigated this further and figured out what the problem is. Inside the websocket_client destructor we join a thread and close the underlying Boost io_service used for websocketpp. If the websocket_client is stored as a global object in side a user's dll and the dll is dynamically loaded unloaded with LoadLibrary/FreeLibrary then the websocket_client's destructor will run as part of [DllMain](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx), therefore holding the loader lock. Now while the destructor is waiting on the thread to exit, that thread when it exits needs to call DllMain notifying about the thread exist (DLL_THREAD_DETACH). Of course that requires the loader lock and so then deadlock occurs. The fix to try and avoid this unfortunately is not straight forward and will require further work. Ideally what should happen is everything should be taken care of in the websocket_client::close(...) API. In the mean time the best workaround is to NOT store any websocket_client objects global, I have confirmed that this works fine. Vivek - can you please confirm that you are indeed using the websocket_client class as a global object? Until fixed you can workaround the issue by not storing the websocket_client object in the global scope. Thanks, Steve
Am trying to use Casablanca as a dll in another third party exe on Windows 7.
Everything works fine, except when closing the socket and unloading the dll.
My close function is as follows
```
void __stdcall WSDisconnect()
{
auto current_context = task_continuation_context::use_default();
create_task([=]()
{
try
{
m_ws_client.close().then([=](task<void> close_task) {
close_task.get();
});
}
catch (websocket_exception& wex)
{
}
}, current_context);
}
```
The close task closes and returns almost immediately, however the call to above function hangs till timeout ( enforced by the third party exe ).
Is this due to trying to use Casablanca on Windows 7 without WinRT, or something else. Any pointers on the fixing the issue welcome.
Regards
Vivek
Comments: Ok I investigated this further and figured out what the problem is. Inside the websocket_client destructor we join a thread and close the underlying Boost io_service used for websocketpp. If the websocket_client is stored as a global object in side a user's dll and the dll is dynamically loaded unloaded with LoadLibrary/FreeLibrary then the websocket_client's destructor will run as part of [DllMain](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx), therefore holding the loader lock. Now while the destructor is waiting on the thread to exit, that thread when it exits needs to call DllMain notifying about the thread exist (DLL_THREAD_DETACH). Of course that requires the loader lock and so then deadlock occurs. The fix to try and avoid this unfortunately is not straight forward and will require further work. Ideally what should happen is everything should be taken care of in the websocket_client::close(...) API. In the mean time the best workaround is to NOT store any websocket_client objects global, I have confirmed that this works fine. Vivek - can you please confirm that you are indeed using the websocket_client class as a global object? Until fixed you can workaround the issue by not storing the websocket_client object in the global scope. Thanks, Steve