RE: [boost] Re: Re: Re: Threads & Exceptions

From: Darryl Green (green_at_[hidden])
Date: 2002-08-11 22:56:01

> -----Original Message-----
> From: William Kempf [mailto:williamkempf_at_[hidden]]
> 
> The problem is that threads are not "async calls" in the way 
> people are 
> envisioning.  They can be used that way, but the typical use 
> is not for 
> that.  Most threads perform some work, and return values (if 
> present) are a 
> side effect.  Take the classic example of the bounded IO 
> monitor.
snip...
> Exception handling in this scenario *must* 
> be addressed on 
> a case by case basis... which means explicit coding.  Calling 
> terminate() is 
> the surest way I know of to ensure the user either does this explicit 
> coding, or the application takes the safest possible course 
> when they don't.

This comes back to the simple issue of what method(s) do we need for dealing
with exceptions in MT C++. If the number of methods is large, then
case-by-case truly is the only option. I am hoping there aren't really all
that many cases to consider.

Obvious cases are:

1) exception must not leave thread. I think the just call terminate() covers
this just fine.

2) exception can leave thread - failing to allow it to propogate by not
calling the appropriate interface in another thread being no different from
failing to ever get the result. We can't prevent this error - do we care?

3) exception can leave thread but MUST propogate - implies some sort of
pre-registration of handler thread? Maybe just pre-registration of some sort
of per-thread handler/wrapper that can access the exception and, if the user
choses, propogate the exception to another thread. If it cant/this bit of
code throws, it is time to terminate().

2 and 3 are probably built on the same facilities anyway? It is just that in
3 I'm thinking of some sort of supervisory thread being notified so it can
do something constructive (attempt a thread restart perhaps), while in 2 I'm
thinking that the thread isn't considered worth supervising - its only the
result that matters, and then only to the thread that asked for it.
 
>   Heck, even the argument that a library may spawn threads that throw 
> exceptions and the user has no control over them seems to me 
> to favor the 
> terminate() approach.  After all, there's not much the 
> application could do 
> to recover from such occurances, since it can't restart the 
> errant thread 
> even if restarting it could be gauranteed to be the correct 
> resolution here. 

I don't want to restart the thread (as such). My concern about this is that
some library author decides it is a really great idea to replace a function
that was running in the calling threads context with one that runs async (in
some sense). As a user of the func, I have been prepared to deal with its
failure (throwing exception) somehow. The func itself doesn't know how to
deal with its own failure - thats why it lets the exception propogate...

>   If you could restart the thread, that means you must have 
> been the one to 
> start it, and thus you could wrap it to prevent exceptions 
> from calling 
> terminate().

The *library* started the thread. It would need to wrap it. I agree it
could. Which lib? How? Will every lib do this differently? Will Dave Moore's
thread pool support some method of doing this for funcs launched that way,
and some other async execution model use another method? What about some
sort of futures object? Does any of this need boost::thread support? The
library writer who uses any of these other libraries in writing something
that has nothing to do with threads as-such isn't the person best placed to
decide how to do this and/or how to implement it. The user just wants
consistent behaviour.

> 
> I understand why people think that async calls should throw, 
> but again, 
> threads are not async calls in the fashion that people are thinking.

No, but they underly them.

If it is your considered opinion that the issues above can be, and are best,
solved outside of boost:thread I'm quite prepared to stop heckling. If you
have already made such a claim I have missed it while following in the
standards related debate.

Regards
Darryl Green.