Re: [Quickfix-developers] WaitForSingleObject deadlock

[Peter P. <pet...@ho...>]

I don't know about the internals of QuickFix but it is not legal to start and stop threads from within the initialisation and shutdown routines of a DLL (DllMain). You may not be doing this explicitly but QuickFix may be trying to clear up its threads when the DLL is unloaded and its static data is deleted automatically. The same effect does not happen when you put the Quickfix code into an EXE rather than a DLL - it is a frustrating limitation of Windows DLLs.

Are you explicitly starting and stopping Quickfix, or do you assume that it will just clean itself up when your main EXE shuts down? If you are not doing so already, you might try creating, initializing and starting the Quickfix objects (Application etc) with an explicit call to the constructor (new CMyApplication etc), and doing the same thing to stop(), shutdown, delete everything explicitly before you unload the DLL or exit your program.

I do not know that this would solve the problem but I have found that threads and DLLs do not mix very happily and doing this might remove the cause of your deadlocks.

Dan

> Date: Fri, 26 Dec 2008 17:25:26 -0500
> From: ael...@gm...
> To: qui...@li...
> Subject: [Quickfix-developers] WaitForSingleObject deadlock
> 
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> while doing some improvements to one of our QF systems, i was running
> into some deadlocks.  one group of which seem to be related to the
> Windows API call to WaitForSingleObject as a thread join mechanism.
> however for some reason in this situation, which is unfortunately
> fairly complicated as I am attempting to extend the functionality of
> another application by creating a DLL and implementing call backs for
> the Application to call into and using an API to call into of the
> applications, which requires that I use the Visual Studio 6 C/C++
> compiler to create this DLL, it seems this call is not behaving itself
> where instead of returning successfully when the thread function
> returns, it's never returning when called with an INFINITE for the
> timeout and returns with a timeout error when specified with a
> timeout, even though the thread in question is returning (logged just
> before return happens and same exact set of codes works where instead
> of calling WaitForSingleObject instead at the end of the thread
> function i set a flag to true signifying completion of thread and then
> check that flag with a threaded sleep instead of calling
> WaitForSingleObject).
> 
> The above solution of course was applied to my application side logic
> where threading was used, however Quickfix is attempting to make use
> of the same Windows API call in Utility.cpp in the thread_join
> function which of course with the above situation is causing any calls
> to thread_join to hang indefinitely.  Does anyone have any ideas why
> this could be happening and a proper way to solve it?
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

_________________________________________________________________
Are you a PC?  Upload your PC story and show the world 
http://clk.atdmt.com/UKM/go/122465942/direct/01/