[cpp-threads] Thread API interface tweaks

[Doug Lea]

Alexander Terekhov wrote:
> On 8/29/06, Peter Dimov <pdimov at mmltd.net> wrote:
> [...]
>> A future<R> has three states, empty (!ready()), after set_value (has a 
>> value
>> of type R) and after set_exception. We can add 'bool has_value() 
>> const' to
> 
> Rather has_exception(). To me it sounds better in the case of futures
> for void functions (with or without throw()-nothing exception specs.)
> 
>> detect the second. Inspecting the exception type would be tricky, though.
> 
> You know that I'm of opinion that C++ EH/ES needs a thorough overhaul.
> Adding extras to support intelligent transportation and
> delivery/inspection across threads/contexts would fit nicely. :-)
> 

Some more unrequested advice based on our experiences in Java.

We found three common usage patterns, all of which we
support in one way or another:
   1. Using a Future to capture and hold task exceptions, so
      that Future.get() throws them rather than returning result.
   2. Using an Executor to trap exceptions, via a user-defined
      interception hook (as in ThreadPoolExecutor.afterExecute).
   3. Using a global handler (in Java, an UncaughtExceptionHandler)
      for worker threads that abort in the course of running submitted
      tasks.

You might think you need only one of these, and of them, (1) is
conceptually the nicest. But for example in pure async mode,
people submit Runnables that are not even wrapped in Futures,
so callers don't ever inspect status. But in some cases they
still want to log exceptions, so use approach (2), or more commonly,
just let them fail all the way through, so use (3).

The main tradeoff in being so flexible is that it took us a while to get
the implementations of these exactly right. (For example, by mistake,
we hadn't routed cases of "Error" exceptions in the same way as
"RuntimeExceptions" in case 2.)

The other tradeoff is that sometime people get themselves in a situation
where they'd like one approach but have already made other design
choices that require another. And complain.

(BTW, the JCilk folks have written a paper describing
a nicely integrated version of approach (1). See:
http://supertech.csail.mit.edu/jCilkImp.html)

-Doug