[ros-dev] [lukeh@padl.com: NPTL and FreeDCE]

[KJKHyperion]

Luke Kenneth Casson Leighton wrote:
> for win32, i am using pthreads-win32: will reactos be able to support the trick that luke howard is referring to?
>   
Its implementation of cancellation violates Windows unwinding 
conventions - i.e. RtlUnwind isn't guaranteed to call cancellation 
handlers, it will only call them if pthreads-win32 is compiled to 
implement cancellation on top of SEH, which it only does for the Visual 
C++ build. Cancellation in pthreads-win32 is, in general, a complete and 
hopeless mess, due to nobody in the UNIX world understanding the 
importance of the fact of stack unwinding being *built into the lowest 
level of the system*. Ignorance spawned misunderstanding spawned bigotry 
spawned hate spawned pain. Pain for us. Specifically, pthreads-win32 
lets you choose between three wrong implementations of cancellation:
 - setjmp/longjmp: the completely worthless "portable" one. Integrates 
only with itself... and depends on the implementation of longjmp. Some 
implementations call RtlUnwind, naive ones don't. Nothing guaranteed
 - C++ exception: largely depends on the compiler's implementation of 
C++ exceptions. GCC is the only Windows compiler to get it completely 
wrong, not even remotely integrating in the system support for exception 
handling and unwinding. Again, unreliable. Depends on the compiler. All 
C++ compilers for Windows (and even some others, like Delphi) get it 
right. The one compiler we painted ourselves in the corner with doesn't
 - SEH: the only reliable implementation. That is, reliable if you 
ignore the C++ compilers that ignore the unwinding standard. Which means 
*your* compiler. Not impossible to express SEH in pure C code, at least 
on the x86 platform (we'll *really* need compiler help for any other 
architecture), as I have proved with with my PSEH library. PSEH has a 
lot of overhead, too, but I can dramatically slim it down to only 
support __try/__finally, which is all you need and removes a pesky 
setjmp that totally fucks with optimizations. Also the implementation of 
cancellation in this mode is wrong, as it should only consist of 
RtlUnwind + ExitThread - in the current implementation, an exception 
filter along the way could abort the cancellation, i.e. if what you 
*really* mean is an exit unwind, perform a goddamn exit unwind
The specification doesn't help at all. Some systems have native 
unwinding, most others don't, they have signals. C++ has unwinding, C 
has signals. C came first. Guess what this means? cancellation isn't 
specified to integrate with C++ signals... nor it's forbidden to. Of 
course unwinding a call stack without calling C++ destructors is 
absolutely wrong, but tell that to the people who depend on that behavior

PS: all cries of "but it's UNDOCUMENTED! PATENTED! mommy sais it will 
make HAIR grow from my PALMS!" will be appropriately derided