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. 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
First
|
Prev
|
Pages: 1 2 Prev: Who could give me an example for enumerate brush? Next: What forms the basis of Skinning ? |