From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-14 22:22:12
Dave's example of needing to eat all exceptions that might come from
a plug-in is good. Another example is with C++ code implementing a
callback that is called from non-C++ code such as the operating
system. Rolling up the operating system's stack without its consent
is bad, so a well-written callback will catch all exceptions before
returning. In general, eating all exceptions is necessary on
boundaries with external code that may not be written in C++, or that
may be in C++ but using a different ABI. I think there are other
cases where catching all exceptions can be justified in terms of
program logic, but this is one where it's absolutely required.
I'm not worried about library code eating thread cancellation
exceptions. The library code has to return sometime, and eventually
the thread will hit another checkpoint and it can throw another
cancellation exception. All the mechanism has to do is not clear the
appropriate flag until the thread is fully canceled. There is little
need to force the cancellation exceptions to automatically rethrow
themselves. In fact, if I have an application where a fair amount of
work needs to be done in order to make the thread state safe to clean
up, being able to stop a cancellation could be a very useful feature.
I would rather have a simple mechanism that is under developer
control, with the concomitant responsibility that my thread code has
to be reasonably well behaved for it to perform well.
When a thread is making a blocking call, the cancellation mechanism
could make available a reference to the condition variable that the
thread is waiting on. This would allow the cancel call to immediately
unblock the thread. It would be easy to do because a thread can wait
on only one thing at a time. However, this could have nasty
consequences on the state of the condition variables and on other
threads, so I think it would be better to keep this feature out.
Compared to the level of self-discipline required for threaded
application developers now, getting code to work with a simple
cancellation mechanism will be a piece of cake. A more complex or
more ambitious mechanism runs the risk of getting in the way of what
the developer has to do, and it could introduce new failure modes. I
think a simple cancellation mechanism will work well in practice.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk