Luke Kenneth Casson Leighton wrote:
On Mon, Jan 31, 2005 at 08:28:53PM -0800, Dan Kegel wrote:
Luke wrote:
it's come to my attention that NPTL cannot cope with jumping outTough noogies, as it were. See
of a cancellation handler.
it'll bother me later but for now it doesn't :)
there is some code in FreeDCE which expects to be able to jump outThen FreeDCE should be fixed to be POSIX-compliant, I think.
of a cancellation handler
Or is there something subtle going on here?
the behaviour of LinuxThreads is different from NPTL.
therefore, given that this cancellation thing matters for dce
applications (the runtime relies on it being possible) i thought
you might wish to be aware of this subtle difference in case
Wine MSRPC or other applications also rely on it.
If I understand it correctly, "cancellation handlers" are used for cleaning up when a thread is terminated. Windows doesn't have an eqivalent feature so if you forcefully terminate a thread then you leak resources and could have terminated with a lock held. However, in kernel designers seem to have thought about this problem and have added features to the one of the locking primitives (the NT mutant, or Win32 mutex, also used by Win32 critical sections) so that if the owning thread was terminated then calls to wait on the lock will return with a error code signaling that the owning thread was terminated so that they can clean up. For more details see here:
http://blogs.msdn.com/larryosterman/archive/2004/09/24/233969.aspx
It doesn't look like cancellation handlers are called by the pthread emulation code, but I can't see why it would be necessary at the moment.
Rob
P.S. Because of the reasons above, using the Win32 TerminateThread function is a sign of bad programming, except when used by a debugger. Similarly, SuspendThread has the problem above that it could suspend a thread whilst inside the heap critical section and similarly, should not be used, except in a debugger.
