[cpp-threads] Asynchronous Function Proposal

[Boehm, Hans]

> From:  Anthony Williams
> Sent: Monday, June 08, 2009 2:53 PM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Asynchronous Function Proposal
> 
> Boehm, Hans wrote:
> > And I don't currently see a reason exceptions shouldn't always be 
> > reported at the request point.
> > 
> > Thinking about this more, I'm not sure I fully understand the 
> > implications of allowing or disallowing execution at the call point.
> 
> If you allow exceptions from the *task* to be thrown at the 
> point of the
> async() call then the user code has to be able to handle them 
> being thrown there, as well as at the future.get() call site. 
> If the async() call throws exceptions on its own (e.g. 
> std::bad_alloc if not enough memory to allocate task) that is 
> a different matter.
> 
> Disallowing exceptions from the task to be thrown at the 
> async() call site doesn't mean the task can't be executed 
> synchronously there --- it just means that the exception must 
> be captured in the unique_future's associated state.
I'm sorry if I wasn't clear.  I agree with all of this, though somewhat tentatively.  I'm a little concerned that there are examples for which deferring an exception like this causes problems, e.g. if a pthread lock is explicitly released in the exception handler.  Hopefully that's rare enough, and the rules are explicit enough that we can live with the consequences.  It's just that I'm not sure I understand all of them, which is my concern with much of this.

Hans