Re: [c++-pthreads] Re: Does the cancelation exception have a name?

[Dave Butenhof <david.butenhof@xxxxxx>]

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.)
begin:vcard
fn:Dave Butenhof
n:Butenhof;Dave
org:Hewlett-Packard Company;Manageability Systems Lab
adr;dom:110 Spit Brook Rd;;ZKO2-3/Q18;Nashua;NH;03062
email;internet:david.butenhof@xxxxxx
title:HP Utility Pricing software agent Technical Lead
tel;work:603.884.7460
note;quoted-printable:POSIX thread standards consultant=0D=0A=
	Author of "Programming With POSIX Threads" (Addison-Wesley)=0D=0A=
	Father to Amy (13) and Alyssa (9)
x-mozilla-html:TRUE
version:2.1
end:vcard