[c++-pthreads] Re: FW: RE: Re: I'm Lost

[Dave Butenhof]

David Abrahams wrote:
> OK, it's a study group.  Slightly more than a mailing list, but hardly
> a committee.  I guess I'm just alarmist.
>   
I shouldn't belabor the point, but it really is just a mailing list at 
this point. That is, membership and participation in the mailing list 
does not imply any formal (or even semi-formal) association with a 
"study group"; just willingness to sign up and maybe read, possibly even 
reply, with no obligation.
>> I guess I'd have to agree that the danger of injecting another exception 
>> type is low. And mostly due to the fact that C++ has no "root exception 
>> type" onto which could be grafted some minimal universal state 
>>     
> It has a de-facto root type: std::exception.
>   
And if it was used universally that would be almost as good as a de-jure 
root type. ;-)
>> (an architected status code space, like VMS condition codes, a
>> descriptive string, etc.) so that nobody would need an anonymous and
>> semantic-free catch(...) just to be sure nothing slipped past.
>>     
> When you have a root type, catching that is practically anonymous and
> semantic-free. It doesn't make much difference in practice.
>   
A root type with properties can be processed and explained, unlike a 
truly anonymous 'catch(...)'. For example, I've been doing a lot of 
programming lately with the WBEM distributed management system. It has a 
C++ layer over the real XML and transport mechanism, making a fairly 
decent RPC. (With some archaic annoyances like non-STL standard strings 
and arrays because it was standardized before the real STL.) But only 
CIM exceptions are carried back "over the wire" from server to client; 
anything else allowed to propagate outside the server-side object comes 
through just as "unknown error". That's the consequence of 'catch(...)'.

If there was a language requirement for example that all exceptions be 
subclasses of std::exception, you could catch(const exception &e) and 
always depend on being able to re-throw 
CIMOperationFailedException(String(e.what())). In terms of code flow, 
the difference is almost irrelevant (though I know of WBEM providers 
that include distinctive text in their exception descriptions and 
clients that parse the text); in terms of human interaction and even 
error logging, the difference is significant.

DCE exceptions carried a standardized error code, which could be 
decyphered into facility and cause fields, and looked up in a message 
catalog. That has even greater advantages for code as well as humans, 
although registering unique facility codes is always a headache.

But, OK, this is entirely off-topic basic C++ stuff, not "C++ pthreads", 
so let's move on... ;-)
> Additional?  I'm lost again.  There is no workable cross-thread throw
> without deferral.  Anything else is an asynchronous exception.
>   
Hmm. So your thread_throw(), like pthread_cancel(), would simply stash 
the exception object away somewhere for the target (victim?) thread to 
throw synchronously at a later time? At the same defined cancellation 
points? At a different set of points? Subject to cancelability state, or 
at the next cancellation point no matter what? Do we need to worry about 
"cancel disabled but other exceptions enabled", or vice versa... and 
will people expect to be able to enable or disable individual exception 
types?
>> And if you're generalizing the unstoppable exception, 
>>     
> Generalizing?
>   
>> I don't quite see how it makes sense not to generalize the deferral,
>> and now cancel really is just a specific predefined exception that
>> can be thrown like any other exception.  That's not necessarily bad;
>> I just don't see how it's a compromise. (A compromise needs to make
>> BOTH sides equally unhappy, not just one side!)
>>     
> The compromise I'm proposing makes it possible to generate an
> unstoppable cancellation (bad for us) while making it ugly and
> unnatural to do so (bad for "the other side").
>   
Ah; I think I misunderstood the semantics of your thread_throw(). From 
your introduction I took it as a mechanism for injecting any exception 
into another thread as "unstoppable". Apparently what you intended was 
that it simply injects ANY exception, and if that happens to be a weird 
"unstoppable" exception it works the same as it would from a normal 
throw within a single call stack.

OK, I get it.

So fine, perhaps that is a viable compromise. I'm not "morally opposed" 
to a generalized cross-thread exception. I'm not thrilled about anyone 
injecting unstoppable exceptions into some "innocent" call stack; but 
like cancellation it can only be done when you at least know the thread 
ID of the call stack (meaning either you created the thread or the 
facility that did made the ID available to you in one way or another, 
though possibly just by making a call into your facility). And if 
someone does it to some arbitrary and unprepared thread it'll may behave 
just as badly as they deserve. ;-)
-------------- 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/aca5e59b/attachment.vcf>