David Abrahams wrote:
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.Dave Butenhof <david.butenhof@xxxxxx> 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.
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.
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 (12) and Alyssa (8) x-mozilla-html:TRUE version:2.1 end:vcard