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

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

Dave Butenhof <david.butenhof@xxxxxx> writes:

>> 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? 

Same points.

> Subject to cancelability state, or at the next cancellation point no
> matter what?

Subject to cancelability.  In C++ "cancelability" would indicate
whether cancellation points can throw (these asynchronously-initiated
exceptions).  I actually think the parenthesized part could be
removed, for all practical purposes.  There's usually little point in
preventing a function from throwing cancellation if it can throw
something else.

> 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?

Naw, I don't think so.  Nobody has mentioned a use case.  If we find
it is suddenly in demand because of some unanticipated use case, that
sort of selective cancelability is pretty easy to add.

>>> 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.

Correct.

> 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. ;-)

Yes.  

I do have sympathy, incidentally, for the other side's desire to "try
really hard" to shut a thread down cleanly.  I just don't happen to
think unstoppable exceptions are a particularly effective tool for
that job.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com