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

[Dave Butenhof]

David Abrahams wrote:
> Dave Butenhof <david.butenhof at hp.com> writes:
>   
>> 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.
>   
Indeed. We went through this with pthread_abort() in POSIX. For the 
embedded realtime environment, it's both possible and often essential to 
forcibly and immediately shut down a nonresponsive thread. In any 
modular programming environment, where you don't control all of the code 
in the process, it's impossible... and you'll get yourself into worse 
trouble by trying.

It all goes back to the fact that threads are just asynchronous 
procedure calls within the same application; they have no real 
independence. Trash one set of invariants, and you can trash the entire 
co-dependent environment with no way to analyze or clean up because of 
all this annoying encapsulation and data hiding stuff. ;-)

An embedded application can know precisely what data any thread might 
have touched, analyze and repair it all; though even there it's not easy 
(or 100% reliable) in any complicated application. When some of the data 
a thread might have touched is in STL, libc, or other libraries, you can 
just forget it. The only way to forcibly trash a thread is to crash the 
entire process and start over.

We didn't accept pthread_abort() because we were too concerned about 
others trying to use it and getting themselves deep in trouble. And this 
is probably well over the line where that was a reasonable decision. 
It's fine for any embedded realtime environment to add its own 
pthread_abort(); it's just not portable. But the application wouldn't 
port anyway to any environment with a different set of state that needed 
to be cleaned (much less any hidden state that can't be cleaned).

If you're just trying to get enough control to exit cleanly, there are 
usually better ways. If you really intend to recover and continue -- 
you're probably already in way over your head. ;-)

A "forced unwind" is both better and worse... it is a cleaner mechanism, 
but if the call stack context is really trashed somehow, you're less 
likely to get the thread to actually terminate that way.
-------------- 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/ccfd1e32/attachment.vcf>