Re: first sight

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.

Regards,

   Tom