From: Joseph M. Newcomer on 8 Feb 2010 13:24
No, MsgWaitForMultipleObjects is *not* the same as WaitForSingleObject, not by a long
shot. It allows concurrent operations such as message dispatching. Generally, I don't
consider using MsgWaitForMultipleObjects a reasonable solution; I just return to the main
message pump, which gives me the same thing with less complexity.
But the number of times I see this with WaitForSingleObject is astonishing. And with the
blocked WaitFor, there is no way to abort it, which is another of the many reasons for
using a thread.
On Mon, 8 Feb 2010 07:57:28 -0800, "David Ching" <dc(a)remove-this.dcsoft.com> wrote:
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>> Anything of the form
>> start thread...
>> wait for thread to finish...
>> is silly. You have created a very expensive and complex subroutine call!
>> You can be
>> reasonably certain that if all you do is launch a single thread and wait
>> for it
>> immediately that you have made a serious design error.
>I have done this - start a thread and use MsgWaitForMultipleObjects() to
>wait for it to finish, while also getting messages that the user has clicked
>the Close button to exit the app. When such a message is received, I can
>signal the thread to terminate or terminate it forcefully in the worst case.
>So yes, it is an expensive subroutine call but one that is abortable. Is
>there a more efficient design pattern for an abortable subroutine call?
Joseph M. Newcomer [MVP]
MVP Tips: http://www.flounder.com/mvp_tips.htm