Luke wrote:
it's come to my attention that NPTL cannot cope with jumping out of a cancellation handler.
Tough noogies, as it were. See http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cleanup_pop....
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? - Dan
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 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.
that's all - nothing more.
l.
Luke Kenneth Casson Leighton wrote:
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.
that's all - nothing more.
Right. Nothing subtle, then. I guess FreeDCE needs some work to run on NPTL or other POSIX-compliant threads packages, as it's using Linuxthreads behavior that is an extension of POSIX threads. (Surely FreeDCE doesn't *need* to longjmp out of a cancellation handler; it can't be that hard to fix.) Thanks for the heads up. - Dan
On Tue, Feb 01, 2005 at 06:56:57AM -0800, Dan Kegel wrote:
Luke Kenneth Casson Leighton wrote:
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.
that's all - nothing more.
Right. Nothing subtle, then. I guess FreeDCE needs some work to run on NPTL or other POSIX-compliant threads packages,
*sigh*. yes. depends on your version of POSIX (final or draft 4).
loic is working on keeping dcethreads "current", at least.
there are approx 350 occurrences of pthread_somethingorother in FreeDCE, so it's not a trivial task, more's the pity.
as it's using Linuxthreads behavior that is an extension of POSIX threads. (Surely FreeDCE doesn't *need* to longjmp out of a cancellation handler;
it's the dcethreads (posix draft 4) emulation library that handles that, from what i can gather.
it can't be that hard to fix.) Thanks for the heads up.
ack.
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 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: 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.
-
Dan Kegel -
Luke Kenneth Casson Leighton -
Robert Shearman