NPTL and Wine threads
rob at codeweavers.com
Tue Feb 1 10:32:20 CST 2005
Luke Kenneth Casson Leighton wrote:
>On Mon, Jan 31, 2005 at 08:28:53PM -0800, Dan Kegel wrote:
>>>it's come to my attention that NPTL cannot cope with jumping out
>>>of a cancellation handler.
>>Tough noogies, as it were. See
> it'll bother me later but for now it doesn't :)
>>>there is some code in FreeDCE which expects to be able to jump out
>>>of a cancellation handler
>>Then FreeDCE should be fixed to be POSIX-compliant, I think.
>>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:
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.
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.
More information about the wine-devel