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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-02-10 10:42:47

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.

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.