[c++-pthreads] Re: [SPAM] - Re: [c++-pthreads] Re: FW: RE: Re: I'm Lost - Email found in subject

[Dave Butenhof]

Ted Baker wrote:
> On Wed, Mar 08, 2006 at 03:15:37PM -0800, Mark Mitchell wrote:
>   
>> Jason Merrill wrote:
>>     
>>> If you can interrupt cancellation, re-cancellation is implemented
>>> trivially simply by just having the cancellation exception destructor
>>> call 'pthread_cancel (pthread_self ())'.  The sticking point is being
>>> able to abort the cancellation in the first place, which is what Uli has
>>> been opposed to.
>>>       
> This would be illegal according to the C API, since once a thread
> begins executing cancellation handlers it becomes (irrevocably)
> not cancellable.  That means a subsequent call to pthread_cancel
> is required to have no effect on the thread.
>   
The C binding is necessarily constrained; but we were careful (as much 
as possible within the restrictions of POSIX scope) to be clear that 
those constraints should not restrict more advanced language 
implementation. In particular, that cancel was always intended to be an 
exception and that in a language with the capability it SHOULD be. That 
of course, can't be stated as a requirement, but it was our intent.
> So, if you want to do this you need a new function that is like
> pthread_cancel but has special semantics.  That is, the developer
> of the C++ binding would need to coordinate with the implementor
> of pthread_cancel to provide this function not in the POSIX C API.
>   
Yes; unfortunately most UNIX systems still lack a cross-language 
exception infrastructure, so C++ and pthread cancel/exit, Ada, Java, and 
so forth have each "rolled their own" largely incompatible interfaces. 
Makes me miss OpenVMS and Tru64 UNIX, which did have common exceptions. 
The original implementation of the POSIX C API, going back way before 
there even WAS a POSIX C API, was based on VMS condition handling (OS 
exceptions) and Tru64 UNIX libexc. Interoperable exception support for 
cancel across C, C++, Ada, etc. was almost free since pretty much 
everyone ran destructors, finally clauses and such even on foreign 
exception unwinds. (Even if they didn't have named exception support to 
catch them.)

Several other mainstream UNIX vendors nearly had a common exception API 
as well as a result of the Itanium UNIX ABI effort, but apparently 
everyone backed off when the group disbanded. (That was a major 
disappointment.)
>> ...  So, it seems like this ought to satisfy everyone from the user-level perspective.
>>     
> I've been talking about the implementor-perspective. A standard will not
> be much good unless you can also persuade the implementors to buy in.
Nor will getting implementors on board if the final form isn't something 
compellingly useful to developers. I have trouble believing that a C++ 
POSIX binding that doesn't use exceptions will be accepted easily, 
widely, or quickly.
-------------- 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/20060308/59da4dae/attachment.vcf>