Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-05-23 10:16:33

graydon hoare wrote:
> run ok. NPTL is just another (better) implementation of the pthreads
> API, so there's every chance of things built for linuxthreads working
> unmodified.
> that said, there's a lot of linuxthreads *behavior* which was cleaned
> up in NPTL (eg. signals) so you may well find a kludge or two which no
> longer need to be used, or which are masking / working around correct
> behavior.

Well, for your information...
(Subject: Re: nptl 0.38)


Ulrich Drepper <drepper redhat com> schrieb am 12.05.03 18:53:43:
> ~ update of the unwinding code to support the compromise wrt C++
> exception handling. catch(...) blocks are also executed in case
> a thread is canceled. Only catch(...), no other catch variant.
> This is only logical since the cancellation has no type representable
> in C++.

Says who? Braindamaged "forced unwinding"-based (for thread cancel
and thread exit, jmps aside for a moment) ABI?
(Subject: Re: Some issues with Technical Report on C++ Performance (DRAFT))

> Note that the catch(...) block has to rethrow the exception;
> otherwise the program will abort.

That's crappy too.
(Subject: Re: PTHREADS: Longjmp()'ing from cleanup handlers)


Sorry, but if you want to "finalize" (catch and continue) a
cancellation, you need a correct and rational implementation
of POSIX threads that implements cancellation as an EXCEPTION
that can be caught. (E.g., with a C++ 'catch(...)', though
having a standard name for the exception would be even better.)

(Subject: Re: __attribute__((cleanup(function)) versus try/finally)
(Subject: Exception handling... it's time to fix the standard)



"}; // Dear WG21 {co-}liaison/member, please:"

Boost list run by bdawes at, gregod at, cpdaniel at, john at