"Peter Dimov" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> "Peter Dimov" <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
