buylotrogold

Hello all, I did a dialog application with an utility class with 2 working threads in it that are calling callback functions of the xxxdlg class. Thead A is my main working thread.  This thread his waiting on 2 events : 1- Quit Event 2- Optional callback call Event This thread is calling a callback function on every WaitForMultiple_object_s() timeout, here 5000 ms. Thread B is an optional thread that can be enable/disable at anytime.  This thread his waiting only a quit Event and when WaitForSingle_object_() timeout it is setting the Optional Event of Thread A via SetEvent().  Timeout here is 15 000 ms. Each Thread are calling AfxEndThread(0,FALSE); at the end and the control function is waiting on A-m_hThread and/or B-m_hThread before deleting their respective _object_. Now, if I am not enabling thread B.  I can start and end Thread A without any issue.  If I start both thread A and B and I can also quit them without problem if they were both running.  Now , If I start both thread A and B and stopping thread B and waiting a 10 seconds when I will try to stop thread A the WaitForSingle_object_() on his handle will deadlock. I have found out that it is related with the event I am using for telling thread A to execute the optional callback.  If I simply put the SetEvent() in comment, the problem never occurs. Any idea, why this is happening? Thank you

Thank you Joseph M. Newcomer [MVP] email: This e-mail address is being protected from spam bots, you need JavaScript enabled to view it Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm

**** I have found out that it is related with the event I am using for telling thread A to execute the optional callback.  If I simply put the SetEvent() in comment, the problem never occurs. **** Callbacks are dangerous as a way of life, especially in C++.  Try to avoid ever using them.  The are an old C hack, rarely, if ever, valid in C++. -1.

**** I have found out that it is related with the event I am using for telling thread A to execute the optional callback.  If I simply put the SetEvent() in comment, the problem never occurs. **** Callbacks are dangerous as a way of life, especially in C++.  Try to avoid ever using them.  The are an old C hack, rarely, if ever, valid in C++. -1. **** However, if you examine the use of most callbacks, they are just C hacks transformed to C++, usually badly.  For example, how many callbacks really carry a user-defined value with them?  Even Microsoft totally screwed this up, and in 20+ years, has not fixed it with some of the enum callbacks, making them impossible to use in C++.  I did not say avoid them , I said try to avoid ever using them .  That's because there are often much better approaches to the problem than a callback.  It was reflexive for C programmers to toss a callback into the mix whenever they felt like it; it is less neccessary in C++, and is often best handled by passing in an _object_ of an abstract superclass with a pure virtual method defined by the DLL interface, except what is passed in is actually an instance of the derived class whose virtual method is specified.  While this sort-of-looks-like a callback, it is philosophically quite different from the C hack, and is a cleaner solution in the C++ world.                                 joe **** Joseph M. Newcomer [MVP] email: This e-mail address is being protected from spam bots, you need JavaScript enabled to view it Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm