From: Joseph M. Newcomer on
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.
joe

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
>news:g2com55923rlh6fcja6s3qf3nek10rsrpe(a)4ax.com...
>> 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?
>
>Thanks,
>David
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm