guys, hi,
am on the mailing list (subscribed) but am not receiving posts: please cc me if this would be an issue.
for win32, i am using pthreads-win32: will reactos be able to support the trick that luke howard is referring to?
l.
----- Forwarded message from Luke Howard lukeh@padl.com -----
Envelope-to: lkcl@localhost Delivery-date: Mon, 24 Apr 2006 12:51:50 +0100 X-Original-To: lkcl@lkcl.net Resent-Date: 24 Apr 2006 10:22:43 -0000 From: Luke Howard lukeh@padl.com Organization: PADL Software Pty Ltd To: freedce-devel@lists.sourceforge.net Subject: NPTL and FreeDCE Cc: opendce@opengroup.org Reply-To: lukeh@padl.com Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: NO, hits=-5.60 required=5.00 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Flag: NO X-Spam-Level: Resent-Message-ID: UQB5HC.A.7PG.ubKTEB@mailman Resent-To: opendce@opengroup.org Resent-From: opendce@opengroup.org X-Mailing-List: opendce:archive/latest/626 Resent-Sender: opendce-request@opengroup.org X-hands-com-MailScanner: Found to be clean X-MailScanner-From: opendce-request@opengroup.org Resent-Date: Mon, 24 Apr 2006 12:51:50 +0100
It may be possible to integrate DCE exception handling and NPTL so that longjmp() is never explicitly called from a cancellation cleanup handler. In fact, cleanup handlers need not be used at all.
This approach requires the NPTL r ather than the LinuxThreads, API and is orthogonal to the previous issue about removing thread cancellation (that was a runtime issue present with NPTL regardless of which header one compiles against).
Instead of calling _pthread_cleanup_push_defer(), we can store a __pthread_unwind_buf_t in the exception context and call __sigsetjmp() and __pthread_register_cancel_defer(). If __sigsetjmp() returns from a longjmp(), then we call dce_pthread_test_exit_np() to test whether the thread was cancelled, and set the current exception to pthread_cancel_e if necessary. No cleanup handler is necessary.
The trick is that the code that raises an exception needs to call the internal API __pthread_unwind(), rather than longjmp(). Of course this ends up calling longjmp() anyway but hopefully does the right thing with respect to any other cleanup handlers that are registered.
Another idea is to use the _Unwind_XXX API, but this strikes me as a little ambitious for now and I don't have any desire to interleave C++ and DCE exceptions.
/* * For the NPTL API we share a setjmp/longjmp buffer between the * pthreads cancellation and DCE exception handling APIs. * * Note that we never actually call the cancellation function, we * just change the current exception context directly; this is the * same as calling dce_ptdexc_raise(&pthread_cancel_e) except that * __pthread_unwind() is not called. */
#define dce_exc_cleanup_push(cu, routine, arg) do \ { \ __exc_occured = __sigsetjmp((struct __jmp_buf_tag *)(cu)->__cancel_buf.__cancel_jmp_buf, 0); \ if (__exc_occured) \ { \ void *__status; \ \ if (dce_pthread_test_exit_np(&__status) == PTHREAD_STATUS_EXIT_NP \ && __status == PTHREAD_CANCELED) \ __exc_ctxt.exc = &pthread_cancel_e; \ } \ else \ { \ __pthread_register_cancel_defer(&(cu)->__cancel_buf); \ } \ } while (0)
#define dce_exc_cleanup_pop(cu, execute) do \ { \ __pthread_unregister_cancel_restore(&(cu)->__cancel_buf); \ } while (0)
/* make this a NOOP because we called it above */ #define dce_exc_setjmp(jmpbuf, val)
/* we call __pthread_unwind() directly from dce_ptdexc_raise() */ #undef dce_exc_longjmp
-- Luke
--
----- End forwarded message -----
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?
Whatever runs in windows should some day run in ReactOS without problems. Please don't add any reactos specific hacks to your software.
- Thomas
On Mon, Apr 24, 2006 at 02:14:47PM +0200, Thomas Weidenmueller wrote:
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?
Whatever runs in windows should some day run in ReactOS without problems. Please don't add any reactos specific hacks to your software.
i haven't.
i checked that it runs (with the same faults) on XP.
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
KJKHyperion wrote:
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
Depends on the GCC you are refer to. Mingw current release yes it not integrated. Dwarf2 exception handling version has integration been in cygwin version for a while even some patches to stop win32 stuff being missed. Normal MS SEH cannot be integrated due to a patent held by Borland what MS and other complier developers pay for. Borland's gcc also does not have the problem.
Libstdc++ used with mingw is a huge bug bear of problems. Libstdc++ is the stand alone version in the release same one you would use on dos or some other platforms without Exception handling. It has hacks to correct ms printf scanf.. functions not compad with gnu printf scanf.... even than the fix is not fully complete. On top of that 4 functions are missing for full Unicode support. Ok we don't need full cygwin support. A few little snips here are there and its C++ would be functional.
Lets just put it this way a better GCC for mingw has been kicking around with Dwarf2 support since 2004. And a gcc with standard SEH has been kicking around from 2000 mind that you mush have a Borland License to use it since the libstdc++ has been replaced with a Borland one and other links to borland libs has been done that the complier seh will not function without. Also a developer on Reactos did a prototype from memory it might have been mingw with standard SEH. Just not legal everywhere.
Yes Linux people understand that exception handling should be in the lower part of the system. Dwarf2/Dwarf3 Standard it used in a lot of places its not locked by patents or anything else.
Peter Dolding
Peter Dolding wrote:
Libstdc++ used with mingw is a huge bug bear of problems. Libstdc++ is the stand alone version in the release same one you would use on dos or some other platforms without Exception handling. It has hacks to correct ms printf scanf.. functions not compad with gnu printf scanf.... even than the fix is not fully complete. On top of that 4 functions are missing for full Unicode support. Ok we don't need full cygwin support. A few little snips here are there and its C++ would be functional.
I don't want to stick C++ everywhere. People make terrible and liberal use of C++. We need exception handling in the kernel and in RPC stubs, and in those contexts <blink>we cannot afford the overhead of careless abuse of C++</blink>. How about Cygwin? what have they done?
Lets just put it this way a better GCC for mingw has been kicking around with Dwarf2 support since 2004. And a gcc with standard SEH has been kicking around from 2000 mind that you mush have a Borland License to use it since the libstdc++ has been replaced with a Borland one and other links to borland libs has been done that the complier seh will not function without. Also a developer on Reactos did a prototype from memory it might have been mingw with standard SEH. Just not legal everywhere.
legality is debatable. A patent shouldn't stop development entirely - in fact, a widely used open-source implementation gives you at least some strength at the bargaining table. If you go empty handed, you can just bow and suck it. I don't believe in this "non-violent"/"sit-in"/"civil disobedience" take on patents, you know what I mean, the "HOW COME ITS STILL PATENT, I SAT HERE DOIN NOTHIN AN' STUFF" thing. Developing a competing standard only works if you can piss off your users with ABI instability, we are a Windows thing and we cannot do that. Either it's SEH or it isn't
Yes Linux people understand that exception handling should be in the lower part of the system. Dwarf2/Dwarf3 Standard it used in a lot of places its not locked by patents or anything else.
it's too late. Signals have been around for too long. And I know that even if they go for a SEH analogue, they'll completely disregard the state of the art (SEH) to create their own competing standard, with identical-but-different structures, constants, etc. (because we all know that camel-case is the ultimate evil, right?), with some shitty justification that translates as "we have a bigger penis". I'm sick of alternatives, I want a replacement for a change
On 4/28/06, KJKHyperion hackbunny@reactos.com wrote:
PS: all cries of "but it's UNDOCUMENTED! PATENTED! mommy sais it will make HAIR grow from my PALMS!" will be appropriately derided
I never objected to forking gcc/g++ and adding support for SEH however we have a lack of developer with the skill needed to do it.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
-
KJKHyperion -
Luke Kenneth Casson Leighton -
Peter Dolding -
Steven Edwards -
Thomas Weidenmueller