[[e-mail]: NPTL and FreeDCE]

[Luke Kenneth Casson Leighton]

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(a)padl.com> -----

Envelope-to: lkcl@localhost
Delivery-date: Mon, 24 Apr 2006 12:51:50 +0100
X-Original-To: lkcl(a)lkcl.net
Resent-Date: 24 Apr 2006 10:22:43 -0000
From: Luke Howard <lukeh(a)padl.com>
Organization: PADL Software Pty Ltd
To: freedce-devel(a)lists.sourceforge.net
Subject: NPTL and FreeDCE
Cc: opendce(a)opengroup.org
Reply-To: lukeh(a)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(a)opengroup.org
Resent-From: opendce(a)opengroup.org
X-Mailing-List: opendce:archive/latest/626
Resent-Sender: opendce-request(a)opengroup.org
X-hands-com-MailScanner: Found to be clean
X-MailScanner-From: opendce-request(a)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 -----

-- 
--
lkcl.net - mad free software computer person, visionary and poet.
--

[Thomas Weidenmueller]

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

[Luke Kenneth Casson Leighton]

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.

-- 
--
lkcl.net - mad free software computer person, visionary and poet.
--

[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

[Peter Dolding]

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

[KJKHyperion]

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

[Steven Edwards]

On 4/28/06, KJKHyperion <hackbunny(a)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