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
> 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
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.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk