From pdimov at mmltd.net  Wed Nov  1 19:18:46 2006
From: pdimov at mmltd.net (Peter Dimov)
Date: Wed, 1 Nov 2006 21:18:46 +0200
Subject: Does the cancelation exception have a name?
Message-ID: <007b01c6fdea$9012bec0$6607a8c0@pdimov2>

Under the current NPTL implementation, can the cancelation exception be 
caught by name (and then rethrown)? If not, are there problems (technical or 
otherwise) with giving it a name so it can be caught?

Motivating example 1:

extern "C" int f() // C API, cancelation point
{
    try
    {
        cpp_implementation();
        return 0; // success
    }
    catch( cancel_exception )
    {
        throw;
    }
    catch( bad_alloc )
    {
        return ENOMEM;
    }
    catch( ... )
    {
        return -1;
    }
}

This is a function with a C interface and a C++ implementation. It 
translates all C++ exceptions into error codes, but the cancelation 
exception is special and needs to be rethrown, or else.

Motivating example 2:

void threadproc()
{
    try
    {
        store_result( user_function() );
    }
    catch( cancel_exception )
    {
        // record that the user task has been canceled
        throw;
    }
    catch( ... )
    {
        // record that the task terminated with an exception
    }
}

Here a user task is executed in a thread, and its result (which can be of an 
arbitrary type) is stored for later use. This enables usage of the form:

future<int> f = call_in_thread( user_function );

// do something to exploit parallelism

int r = f.get();

If the cancelation exception is and will remain unnamed, is it possible to 
provide a way to detect, in a catch( ... ) clause, whether the current 
exception is a cancelation exception? Something like

bool is_cancel_exception();

could also allow the two use patterns above.

Thanks in advance for any replies or comments. 



From drow at false.org  Wed Nov  1 20:10:57 2006
From: drow at false.org (Daniel Jacobowitz)
Date: Wed, 1 Nov 2006 15:10:57 -0500
Subject: [c++-pthreads] Does the cancelation exception have a name?
In-Reply-To: <007b01c6fdea$9012bec0$6607a8c0@pdimov2>
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2>
Message-ID: <20061101201057.GA19949@nevyn.them.org>

On Wed, Nov 01, 2006 at 09:18:46PM +0200, Peter Dimov wrote:
> Under the current NPTL implementation, can the cancelation exception be 
> caught by name (and then rethrown)? If not, are there problems (technical 
> or otherwise) with giving it a name so it can be caught?

The latest state I know of for this question is here:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145

-- 
Daniel Jacobowitz
CodeSourcery


From pdimov at mmltd.net  Wed Nov  1 22:31:40 2006
From: pdimov at mmltd.net (Peter Dimov)
Date: Thu, 2 Nov 2006 00:31:40 +0200
Subject: [c++-pthreads] Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org>
Message-ID: <022501c6fe05$818ab2c0$6607a8c0@pdimov2>

Daniel Jacobowitz wrote:
> On Wed, Nov 01, 2006 at 09:18:46PM +0200, Peter Dimov wrote:
>> Under the current NPTL implementation, can the cancelation exception
>> be caught by name (and then rethrown)? If not, are there problems
>> (technical or otherwise) with giving it a name so it can be caught?
>
> The latest state I know of for this question is here:
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145

Thanks!

We are currently discussing, on the c++std-ext reflector, the possible 
approaches for a C++ cancelation/retirement/interruption mechanism. So I was 
trying to decide whether imposing a requirement that the cancel exception 
has a C++ type by which it can be caught is workable and reasonable. It 
seems to be both. 



From terekhov at web.de  Thu Nov  2 10:07:09 2006
From: terekhov at web.de (Alexander Terekhov)
Date: Thu, 02 Nov 2006 11:07:09 +0100
Subject: Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <022501c6fe05$818ab2c0$6607a8c0@pdimov2>
Message-ID: <4549C34D.ACDC575@web.de>


Peter Dimov wrote:
[...]
> We are currently discussing, on the c++std-ext reflector, the possible
> approaches for a C++ cancelation/retirement/interruption mechanism. So I was
> trying to decide whether imposing a requirement that the cancel exception
> has a C++ type by which it can be caught is workable and reasonable. It
> seems to be both.

Don't forget pthread_exit() and longjmp() (there should be a base class 
ala thread_termination_request for thread cancel and thread exit 
exceptions). Time to kill ugly forced unwind altogether (getting rid of 
undefined behavior resulting from "more restricted behavior" for longjmp() 
would not hurt either). 

regards,
alexander.



From pdimov at mmltd.net  Sat Nov  4 17:04:48 2006
From: pdimov at mmltd.net (Peter Dimov)
Date: Sat, 4 Nov 2006 19:04:48 +0200
Subject: [c++-pthreads] Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org>
Message-ID: <009001c70033$578e3ca0$6607a8c0@pdimov2>

Daniel Jacobowitz wrote:

> The latest state I know of for this question is here:
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145

Follow-up question:

Is it possible (and desirable) to give different names to the two 
"exceptions" resulting from pthread_cancel and pthread_exit? 



From terekhov at web.de  Sat Nov  4 21:06:13 2006
From: terekhov at web.de (Alexander Terekhov)
Date: Sat, 04 Nov 2006 22:06:13 +0100
Subject: Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>
Message-ID: <454D00C5.AD892324@web.de>

Google pthread_exit_e.

regards,
alexender.



From terekhov at web.de  Sat Nov  4 21:25:50 2006
From: terekhov at web.de (Alexander Terekhov)
Date: Sat, 04 Nov 2006 22:25:50 +0100
Subject: Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2> <454D00C5.AD892324@web.de>
Message-ID: <454D055E.2896C0C@web.de>

#define PTHREAD_CANCELED std::thread_canceled()

struct thread_canceled {
  operator void * () { return &unique; }
  static thread_canceled unique;
};

extern "C" void pthread_exit(void * ptr)
	throw(std::thread_termination_request) {
  ptr == PTHREAD_CANCELED ? std::thread_cancel() :
                            std::thread_exit(ptr);

} 
template<typename T>
void thread_exit(T value) {
  assert(std::thread_self().can_exit_with<T>());
  throw thread_exit_value(value);
}

template<>
void thread_exit(std::thread_canceled) {
  thread_cancel();
}

void thread_cancel() {
  throw std::thread_cancel_request();
} 

regards,
alexender.



From pdimov at mmltd.net  Sat Nov  4 21:28:26 2006
From: pdimov at mmltd.net (Peter Dimov)
Date: Sat, 4 Nov 2006 23:28:26 +0200
Subject: [c++-pthreads]  Re: Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>  <454D00C5.AD892324@web.de>
Message-ID: <002201c70058$2b5c9bc0$6607a8c0@pdimov2>

Alexander Terekhov wrote:
> Google pthread_exit_e.

I know about DEC pthread_exit_e, my question was more about g++/glibc/NPTL's 
implementation and how the people involved feel. DEC's exception doesn't 
have a C++ name, by the way, so it doesn't matter from a (standard) C++ 
perspective whether it's distinct from pthread_cancel_e.

Restated, the question is what a C++ threading proposal for the next 
standard should contain with respect to the exception types:

A. nothing

B.

namespace std
{
    typedef /* unspecified */ thread_cancel_exception; // matches cancel and 
exit
};

C.

namespace std
{
    typedef /* unspecified */ thread_cancel_exception;
    typedef /* unspecified */ thread_exit_exception;
};



From terekhov at web.de  Mon Nov  6 05:31:04 2006
From: terekhov at web.de (Alexander Terekhov)
Date: Mon, 06 Nov 2006 06:31:04 +0100
Subject: Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>  <454D00C5.AD892324@web.de> <002201c70058$2b5c9bc0$6607a8c0@pdimov2>
Message-ID: <454EC898.A1580D77@web.de>


Peter Dimov wrote:
> 
> Alexander Terekhov wrote:
> > Google pthread_exit_e.
> 
> I know about DEC pthread_exit_e, my question was more about g++/glibc/NPTL's
> implementation and how the people involved feel. DEC's exception doesn't
> have a C++ name, by the way, 

http://groups.google.com/group/comp.programming.threads/msg/271124f3a0517204

"C++ doesn't have a name for those "foreign" exceptions. (Of course 
destructors work fine.) We've worked with the compiler group to add 
some builtin exception subclasses to deal with that, but we never 
found the time to finish hooking up all the bits."

>                              so it doesn't matter from a (standard) C++
> perspective whether it's distinct from pthread_cancel_e.
> 
> Restated, the question is what a C++ threading proposal for the next
> standard should contain with respect to the exception types:
> 
> A. nothing
> 
> B.
> 
> namespace std
> {
>     typedef /* unspecified */ thread_cancel_exception; // matches cancel and
> exit
> };
> 
> C.
> 
> namespace std
> {
>     typedef /* unspecified */ thread_cancel_exception;
>     typedef /* unspecified */ thread_exit_exception;
> };

D. 

   std::thread_termination_request (base for cancel and exit)
   std::thread_cancel_exception
   std::thread_exit_exception<T>
   std::thread_longjmp_exception

regards,
alexander.



From david.butenhof at hp.com  Mon Nov  6 10:23:02 2006
From: david.butenhof at hp.com (Dave Butenhof)
Date: Mon, 06 Nov 2006 05:23:02 -0500
Subject: [c++-pthreads]  Re: Does the cancelation exception have a name?
In-Reply-To: <454EC898.A1580D77@web.de>
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>  <454D00C5.AD892324@web.de> <002201c70058$2b5c9bc0$6607a8c0@pdimov2> <454EC898.A1580D77@web.de>
Message-ID: <454F0D06.7050706@hp.com>

Alexander Terekhov wrote:
> Peter Dimov wrote:
>   
>> Alexander Terekhov wrote:
>>     
>>> Google pthread_exit_e.
>>>       
>> I know about DEC pthread_exit_e, my question was more about g++/glibc/NPTL's
>> implementation and how the people involved feel. DEC's exception doesn't
>> have a C++ name, by the way, 
>>     
> http://groups.google.com/group/comp.programming.threads/msg/271124f3a0517204
>
> "C++ doesn't have a name for those "foreign" exceptions. (Of course 
> destructors work fine.) We've worked with the compiler group to add 
> some builtin exception subclasses to deal with that, but we never 
> found the time to finish hooking up all the bits."
>   
Alexander; perhaps the most telling part of the article you quote here 
is that I wrote it 6 years ago tomorrow; and we still don't have a 
standard for integration of threads and C++, and with Tru64 UNIX reduced 
to irrelevance I don't think there's any current commercial UNIX that's 
even tried to do it right. I feel like everything that can be said has 
circulated more than just a few times before, with little effect. Kinda 
frustrating, really.
> D. 
>
>    std::thread_termination_request (base for cancel and exit)
>    std::thread_cancel_exception
>    std::thread_exit_exception<T>
>    std::thread_longjmp_exception
>   
Yes, absolutely; the parenthesized bit being the most important part... 
a common base class for cancel and exit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20061106/01fca850/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.butenhof.vcf
Type: text/x-vcard
Size: 476 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20061106/01fca850/attachment.vcf>

From pdimov at mmltd.net  Mon Nov  6 14:16:11 2006
From: pdimov at mmltd.net (Peter Dimov)
Date: Mon, 6 Nov 2006 16:16:11 +0200
Subject: [c++-pthreads]  Re: Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>  <454D00C5.AD892324@web.de> <002201c70058$2b5c9bc0$6607a8c0@pdimov2> <454EC898.A1580D77@web.de> <454F0D06.7050706@hp.com>
Message-ID: <00ad01c701ae$48062cd0$6607a8c0@pdimov2>

Dave Butenhof wrote:
> Alexander Terekhov wrote:
>> Peter Dimov wrote:
>>
>>> Alexander Terekhov wrote:
>>>
>>>> Google pthread_exit_e.
>>>>
>>> I know about DEC pthread_exit_e, my question was more about
>>> g++/glibc/NPTL's implementation and how the people involved feel.
>>> DEC's exception doesn't have a C++ name, by the way,
>>>
>> http://groups.google.com/group/comp.programming.threads/msg/271124f3a0517204
>>
>> "C++ doesn't have a name for those "foreign" exceptions. (Of course
>> destructors work fine.) We've worked with the compiler group to add
>> some builtin exception subclasses to deal with that, but we never
>> found the time to finish hooking up all the bits."
>>
> Alexander; perhaps the most telling part of the article you quote here
> is that I wrote it 6 years ago tomorrow; and we still don't have a
> standard for integration of threads and C++, and with Tru64 UNIX
> reduced to irrelevance I don't think there's any current commercial
> UNIX that's even tried to do it right. I feel like everything that
> can be said has circulated more than just a few times before, with
> little effect. Kinda frustrating, really.

The difference this time around is that some of us are trying to write a 
formal proposal for the planned

"30 - Threading API
This section is a placeholder. The next C++ standard is intended to include 
support for a threading API. This feature is intended to provide support for 
synchronization facilities and thread launching and joining. For more 
information and snapshots of current draft proposals still under discussion 
and development, see: N1907, N2090."

section of the next C++ standard.

The frustrating part is that C++ folks say "we need buy-in from vendors" and 
vendors say nothing, apparently just waiting to see what the C++ standard 
will say. :-)

>>    std::thread_termination_request (base for cancel and exit)
>>    std::thread_cancel_exception
>>    std::thread_exit_exception<T>
>>    std::thread_longjmp_exception
>
> Yes, absolutely; the parenthesized bit being the most important
> part... a common base class for cancel and exit.

I've absolutely no problem with that (from a C++ perspective), as long as 
it's implementable. There isn't much point in demanding something in the C++ 
standard that will be universally ignored.



From david.butenhof at hp.com  Mon Nov  6 14:41:16 2006
From: david.butenhof at hp.com (Dave Butenhof)
Date: Mon, 06 Nov 2006 09:41:16 -0500
Subject: [c++-pthreads]  Re: Does the cancelation exception have a name?
In-Reply-To: <00ad01c701ae$48062cd0$6607a8c0@pdimov2>
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>  <454D00C5.AD892324@web.de> <002201c70058$2b5c9bc0$6607a8c0@pdimov2> <454EC898.A1580D77@web.de> <454F0D06.7050706@hp.com> <00ad01c701ae$48062cd0$6607a8c0@pdimov2>
Message-ID: <454F498C.40706@hp.com>

Peter Dimov wrote:
> Dave Butenhof wrote:
>> Alexander Terekhov wrote:
>>> Peter Dimov wrote:
>>>> Alexander Terekhov wrote:
>>>>> Google pthread_exit_e.
>>>> I know about DEC pthread_exit_e, my question was more about
>>>> g++/glibc/NPTL's implementation and how the people involved feel.
>>>> DEC's exception doesn't have a C++ name, by the way,
>>> http://groups.google.com/group/comp.programming.threads/msg/271124f3a0517204 
>>>
>>>
>>> "C++ doesn't have a name for those "foreign" exceptions. (Of course
>>> destructors work fine.) We've worked with the compiler group to add
>>> some builtin exception subclasses to deal with that, but we never
>>> found the time to finish hooking up all the bits."
>> Alexander; perhaps the most telling part of the article you quote here
>> is that I wrote it 6 years ago tomorrow; and we still don't have a
>> standard for integration of threads and C++, and with Tru64 UNIX
>> reduced to irrelevance I don't think there's any current commercial
>> UNIX that's even tried to do it right. I feel like everything that
>> can be said has circulated more than just a few times before, with
>> little effect. Kinda frustrating, really.
> The difference this time around is that some of us are trying to write 
> a formal proposal for the planned
>
> "30 - Threading API
> This section is a placeholder. The next C++ standard is intended to 
> include support for a threading API. This feature is intended to 
> provide support for synchronization facilities and thread launching 
> and joining. For more information and snapshots of current draft 
> proposals still under discussion and development, see: N1907, N2090."
>
> section of the next C++ standard.
Sure; but it's not so clear that's "a difference" since many people had 
a similar intent back then. In fact the first post to THIS mailing list 
was nearly 3 years ago, and various other mailing lists related to the 
subject of C++ and threads, and especially to standardization thereof, 
have come and gone -- and generally stayed pretty quiet.
> The frustrating part is that C++ folks say "we need buy-in from 
> vendors" and vendors say nothing, apparently just waiting to see what 
> the C++ standard will say. :-)
The vendors (or more generally, "implementors") are supposed to be 
participating in the standards process -- certainly they should have a 
vested interest in doing so, and perhaps more to the point 
standardization without them would pretty much be operating in a vacuum. 
If the C++ committee isn't confident of its ability to speak for some 
reasonable number of vendors and for the implementability of the 
standard, then I'd say the whole effort would be pretty well doomed from 
the beginning. And perhaps that's precisely why we've been hanging in 
limbo for (over) 6 years. But that can't really be the case... can it?
>>>    std::thread_termination_request (base for cancel and exit)
>>>    std::thread_cancel_exception
>>>    std::thread_exit_exception<T>
>>>    std::thread_longjmp_exception
>> Yes, absolutely; the parenthesized bit being the most important
>> part... a common base class for cancel and exit.
> I've absolutely no problem with that (from a C++ perspective), as long 
> as it's implementable. There isn't much point in demanding something 
> in the C++ standard that will be universally ignored.
Yes, there are times when it's impossible, or at least impractical, to 
do the right thing. (Though I doubt this is one of those cases.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.butenhof.vcf
Type: text/x-vcard
Size: 476 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20061106/ccb70448/attachment.vcf>

From jason at redhat.com  Mon Nov  6 16:39:55 2006
From: jason at redhat.com (Jason Merrill)
Date: Mon, 06 Nov 2006 11:39:55 -0500
Subject: [c++-pthreads] Does the cancelation exception have a name?
In-Reply-To: <009001c70033$578e3ca0$6607a8c0@pdimov2>
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>
Message-ID: <454F655B.2020200@redhat.com>

Peter Dimov wrote:
> Daniel Jacobowitz wrote:
> 
>> The latest state I know of for this question is here:
>>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
> 
> Follow-up question:
> 
> Is it possible (and desirable) to give different names to the two 
> "exceptions" resulting from pthread_cancel and pthread_exit?

It's not trivial, the information my implementation checks only 
identifies forced unwind, but I don't see any reason it shouldn't be 
possible by putting the extra information somewhere.  It certainly seems 
desirable.

Jason


From pdimov at mmltd.net  Mon Nov  6 15:03:31 2006
From: pdimov at mmltd.net (Peter Dimov)
Date: Mon, 6 Nov 2006 17:03:31 +0200
Subject: [c++-pthreads]  Re: Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>  <454D00C5.AD892324@web.de> <002201c70058$2b5c9bc0$6607a8c0@pdimov2> <454EC898.A1580D77@web.de> <454F0D06.7050706@hp.com> <00ad01c701ae$48062cd0$6607a8c0@pdimov2> <454F498C.40706@hp.com>
Message-ID: <001001c701b4$bedd1750$6607a8c0@pdimov2>

Dave Butenhof wrote:
> Peter Dimov wrote:
>> Dave Butenhof wrote:
>>> Alexander Terekhov wrote:
>>>> Peter Dimov wrote:
>>>>> Alexander Terekhov wrote:
>>>>>> Google pthread_exit_e.
>>>>> I know about DEC pthread_exit_e, my question was more about
>>>>> g++/glibc/NPTL's implementation and how the people involved feel.
>>>>> DEC's exception doesn't have a C++ name, by the way,
>>>> http://groups.google.com/group/comp.programming.threads/msg/271124f3a0517204
>>>>
>>>>
>>>> "C++ doesn't have a name for those "foreign" exceptions. (Of course
>>>> destructors work fine.) We've worked with the compiler group to add
>>>> some builtin exception subclasses to deal with that, but we never
>>>> found the time to finish hooking up all the bits."
>>> Alexander; perhaps the most telling part of the article you quote
>>> here is that I wrote it 6 years ago tomorrow; and we still don't
>>> have a standard for integration of threads and C++, and with Tru64
>>> UNIX reduced to irrelevance I don't think there's any current
>>> commercial UNIX that's even tried to do it right. I feel like
>>> everything that can be said has circulated more than just a few
>>> times before, with little effect. Kinda frustrating, really.
>> The difference this time around is that some of us are trying to
>> write a formal proposal for the planned
>>
>> "30 - Threading API
>> This section is a placeholder. The next C++ standard is intended to
>> include support for a threading API. This feature is intended to
>> provide support for synchronization facilities and thread launching
>> and joining. For more information and snapshots of current draft
>> proposals still under discussion and development, see: N1907, N2090."
>>
>> section of the next C++ standard.

> Sure; but it's not so clear that's "a difference" since many people
> had a similar intent back then. In fact the first post to THIS
> mailing list was nearly 3 years ago, and various other mailing lists
> related to the subject of C++ and threads, and especially to
> standardization thereof, have come and gone -- and generally stayed
> pretty quiet.

This time we have a deadline to meet. My current understanding is that the 
placeholder section above has already been voted into the working paper by 
an official ISO formal motion, and the intent of the committee is that in 
'C++0X', X should be decimal. :-) In practice this means that the threading 
API proposal is already late by one meeting. 



From pdimov at mmltd.net  Mon Nov  6 16:54:28 2006
From: pdimov at mmltd.net (Peter Dimov)
Date: Mon, 6 Nov 2006 18:54:28 +0200
Subject: [c++-pthreads] Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2> <454F655B.2020200@redhat.com>
Message-ID: <00ac01c701c4$3ae5e070$6607a8c0@pdimov2>

Jason Merrill wrote:
> Peter Dimov wrote:
>> Daniel Jacobowitz wrote:
>>
>>> The latest state I know of for this question is here:
>>>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
>>
>> Follow-up question:
>>
>> Is it possible (and desirable) to give different names to the two
>> "exceptions" resulting from pthread_cancel and pthread_exit?
>
> It's not trivial, the information my implementation checks only
> identifies forced unwind, but I don't see any reason it shouldn't be
> possible by putting the extra information somewhere.  It certainly
> seems desirable.

>From looking at the code, it seems possible for pthread_exit and 
pthread_cancel to put something into _Unwind_Exception::exception_class (or 
private_1/private_2) that could allow an extension of your patch to match 
them as if by name. But I'm definitely not an expert on this, so I thought 
it'd be better to ask. 



From jakub at redhat.com  Tue Nov  7 09:30:05 2006
From: jakub at redhat.com (Jakub Jelinek)
Date: Tue, 7 Nov 2006 04:30:05 -0500
Subject: [c++-pthreads] Does the cancelation exception have a name?
In-Reply-To: <00ac01c701c4$3ae5e070$6607a8c0@pdimov2>
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2> <454F655B.2020200@redhat.com> <00ac01c701c4$3ae5e070$6607a8c0@pdimov2>
Message-ID: <20061107093005.GM24872@devserv.devel.redhat.com>

On Mon, Nov 06, 2006 at 06:54:28PM +0200, Peter Dimov wrote:
> Jason Merrill wrote:
> >Peter Dimov wrote:
> >>Daniel Jacobowitz wrote:
> >>
> >>>The latest state I know of for this question is here:
> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
> >>
> >>Follow-up question:
> >>
> >>Is it possible (and desirable) to give different names to the two
> >>"exceptions" resulting from pthread_cancel and pthread_exit?
> >
> >It's not trivial, the information my implementation checks only
> >identifies forced unwind, but I don't see any reason it shouldn't be
> >possible by putting the extra information somewhere.  It certainly
> >seems desirable.
> 
> >From looking at the code, it seems possible for pthread_exit and 
> pthread_cancel to put something into _Unwind_Exception::exception_class (or 
> private_1/private_2) that could allow an extension of your patch to match 
> them as if by name. But I'm definitely not an expert on this, so I thought 
> it'd be better to ask. 

Only in _Unwind_Exception::exception_class, private_{1,2} are used and
initialized within _Unwind_ForcedUnwind.
But guess NPTL could initialize exception_class to GNUthre\0 resp. GNUthrc\0
for pthread_exit resp. pthread_cancel instead of GNUCC++\0 which is used
by GCC __cxa_throw or 0 which is used by NPTL ATM.

	Jakub


From terekhov at web.de  Tue Nov  7 10:23:10 2006
From: terekhov at web.de (Alexander Terekhov)
Date: Tue, 07 Nov 2006 11:23:10 +0100
Subject: Does the cancelation exception have a name?
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2> <454F655B.2020200@redhat.com> <00ac01c701c4$3ae5e070$6607a8c0@pdimov2> <20061107093005.GM24872@devserv.devel.redhat.com>
Message-ID: <45505E8E.5F2FBC32@web.de>


Jakub Jelinek wrote:
[...]
> > pthread_cancel to put something into _Unwind_Exception::exception_class (or
> > private_1/private_2) that could allow an extension of your patch to match
> > them as if by name. But I'm definitely not an expert on this, so I thought
> > it'd be better to ask.
> 
> Only in _Unwind_Exception::exception_class, private_{1,2} are used and
> initialized within _Unwind_ForcedUnwind.

Get rid of forced unwind. What's the problem with ordinary thrown
cancel and exit exceptions?

regards,
alexander.



From david.butenhof at hp.com  Tue Nov  7 11:27:42 2006
From: david.butenhof at hp.com (Dave Butenhof)
Date: Tue, 07 Nov 2006 06:27:42 -0500
Subject: [c++-pthreads]  Re: Does the cancelation exception have a name?
In-Reply-To: <001001c701b4$bedd1750$6607a8c0@pdimov2>
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2> <20061101201057.GA19949@nevyn.them.org> <009001c70033$578e3ca0$6607a8c0@pdimov2>  <454D00C5.AD892324@web.de> <002201c70058$2b5c9bc0$6607a8c0@pdimov2> <454EC898.A1580D77@web.de> <454F0D06.7050706@hp.com> <00ad01c701ae$48062cd0$6607a8c0@pdimov2> <454F498C.40706@hp.com> <001001c701b4$bedd1750$6607a8c0@pdimov2>
Message-ID: <45506DAE.1070308@hp.com>

Peter Dimov wrote:
> This time we have a deadline to meet. My current understanding is that 
> the placeholder section above has already been voted into the working 
> paper by an official ISO formal motion, and the intent of the 
> committee is that in 'C++0X', X should be decimal. :-) In practice 
> this means that the threading API proposal is already late by one 
> meeting.
This line of cynicism has already been carried too far, but if I HAD 
been inclined to pointlessly continue it, I might have been tempted to 
point out that one could see a "down side" when "they're determined to 
have something in the next 3 years and the proposal is already late by 
one meeting" is "the good news". ;-)

But really, although the "endless story" aspect of all this is amusing I 
really don't intend to be seriously cynical. I'm glad people have been 
thinking about it, I think there HAS been an increasing understanding 
and maturity on the subject, there are some proposals on the table that 
have some merit, and there's a pretty decent chance there'll be 
something in the standard that's meaningful. And that's all good.

Best of all, a C++ cancel/exit model based on exceptions will put 
pressure on implementors for a common exception engine (as in Tru64 UNIX 
;-) ) for C and C++ because NON-integrated cancel will be a mess for 
everyone. But that pressure WILL meet with substantial resistance, and 
there's going to be a trainwreck as people shake out their brand new 
cool C++ code and find it doesn't work with C code any more than when 
C++ didn't know about threads at all. C++ can't fix that... but most C++ 
implementors are also C implementors and CAN. Will they?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.butenhof.vcf
Type: text/x-vcard
Size: 476 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20061107/eaeba16d/attachment.vcf>

From gdr at integrable-solutions.net  Tue Nov  7 11:27:14 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 07 Nov 2006 12:27:14 +0100
Subject: [c++-pthreads]  Re: Does the cancelation exception have a name?
In-Reply-To: <001001c701b4$bedd1750$6607a8c0@pdimov2>
References: <007b01c6fdea$9012bec0$6607a8c0@pdimov2>
	<20061101201057.GA19949@nevyn.them.org>
	<009001c70033$578e3ca0$6607a8c0@pdimov2> <454D00C5.AD892324@web.de>
	<002201c70058$2b5c9bc0$6607a8c0@pdimov2> <454EC898.A1580D77@web.de>
	<454F0D06.7050706@hp.com> <00ad01c701ae$48062cd0$6607a8c0@pdimov2>
	<454F498C.40706@hp.com> <001001c701b4$bedd1750$6607a8c0@pdimov2>
Message-ID: <m3fycvcx9p.fsf@zeus.integrable-solutions.net>

"Peter Dimov" <pdimov at mmltd.net> writes:

[...]

| This time we have a deadline to meet. My current understanding is that
| the placeholder section above has already been voted into the working
| paper by an official ISO formal motion,

Your wording might lead to deceptive interpretation.

It was a registration ballot (a bureaucratic process), informing the
community that the C++ committee promises to deliver that as part of
the next  version of C++.  Nobody has voted anything into the working
paper yet.  Nobody is going to vote something in the working paper
without seeing what exactly what the words say.  We still have lot of
work ahead.

-- Gaby