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