[boost] Re: Attempting resolution of Threads & Exceptions Issue

From: Alexander Terekhov (TEREKHOV_at_[hidden])
Date: 2002-08-13 10:45:42

William E. Kempf wrote:
[...]
> However, the point is probably irrelavant, since I think I'm convinced
> that strict termination is too difficult to use.

"On Digital UNIX, an unhandled exception in a thread will terminate the
 process -- and I believe that's the best possible implementation. The
 thread is an inseparable part of the application, not a safely protected
 address space like a process. If it's gone awry for reasons you don't
 understand, the entire process is suspect.

 An unhandled signal WILL terminate the process, so there's no such thing
 (in POSIX) as a thread dying from a signal. Again, if you're working with
 some non-portable extensions that allow an individual thread to die of a
 signal, then you need to look to that implementation to provide whatever
 assistance you require. And, again, I think such an implementation would
 be a bad idea. We originally did that with DCE threads, and came to
realize
 how dangerous it was. When a thread gets a SIGSEGV, there's something
wrong
 with its code or address space -- and the other threads in the process
have
 the same problem. There's no protection. You're best off just taking the
 core dump and figuring out what happened. If you really need "fail
safety",
 then fork the process from a "watcher" that takes the SIGCHLD (or just
 waits) and forks a new, clean, copy to start over.

 And, finally, even if your implementation doesn't terminate the process
 on an unhandled signal or exception, and even if it allows you to capture
 the termination status with something like pthread_join, beware of the
 consequences of breaking the code that created the thread, expecting to
 later join with it itself." --Mr.B

regards,
alexander.