Is the behavior in Win32 defined for such case?
Will this result in that WaitForSingleObject() entering a deadlock?
Or is the system smart enough to let WaitForSingleObject() with some
kind of diagnostic/error code?
Thanks,
Chris
If you really want to know then you'll have to try it and see. The result
is not defined by Win32, and doing this would be considered a design error.
--
Scott McPhillips [VC++ MVP]
Thanks, Scott. Your reply prompted me to look again at the
documentation for WaitForSingleObject() and sure enough it clearly
says that the behavior for such case is undefined. I somehow
overlooked that sentence.
So does this mean that if I initialize a subsystem in which there is a
WaitForSingleObject(), there is no way of "un-initializing" it? The
only way out is killing the process (exiting the program)?
Thanks,
Chris
Can you arrange for the event to become set so that the wait ends normally?
Norm
--
Norm
To reply, change domain to an adult feline.
"Norman Bullen" <no...@BlackKittenAssociates.com> wrote in message
news:13p2ibb...@corp.supernews.com...
I'm not exactly sure what you are trying to do, but this should work:
h = DuplicateHandle(h);
WaitFor..(h);
CloseHandle(h);
That way, even calling CloseHandle() from a different thread doesn't destroy
the event. I'm not 100% sure if event handles can be duplicated though, but
the returnvalue and documentation of DuplicateHandle() will tell you. ;)
Other than that, you can use two events, one for the actual task, the other
to signal the thread to terminate.
Uli
--
Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932