28 Apr
2006
28 Apr
'06
7:12 p.m.
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