Re: [boost] Re: A new boost::thread implementation?

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-10 10:59:58

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> We have three concepts: Runnable, Executor (executes Runnables), and
>>> HasResult (for lack of a better name.) The AsyncCall concept I had
>>> in mind is both Runnable and HasResult, so it can't use operator()
>>> for both. x.result() or result(x) are both fine for HasResult.
>>
>> I see that you separate the initiation of the call from its creation.
>> I was going under the assumption that a call IS a call, i.e. verb, and
>> it starts when you construct it.  An advantage of this arrangement is
>> that you get simple invariants: you don't need to handle the "tried to
>> get the result before initiating the call" case.  Are there
>> disadvantages?
>
> No, the "tried to get the result but the call did not complete" case needs
> to be handled anyway. The call may have been initiated but ended with an
> exception.

Yes, good point.  It's still one fewer case to handle, though.  I
prefer interfaces which disallow erroneous usage, and asking for the
result before the call is even initiated is definitely erroneous.

> This particular arrangement is one way to cleanly separate the
> synchronization/result storage/exception translation from the actual
> execution: async_call doesn't know anything about threads or thread pools.
> Other alternatives are possible, too, but I think that we've reached the
> point where we need actual code and not just made-up syntax.

Agreed.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com