From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-02-10 12:54:28
William E. Kempf wrote:
>> From: "Peter Dimov" <pdimov_at_[hidden]>
>>>> // step 2: execute an async_call
>>> This example, and the implementation above, are just complex
>>> synchronous calls. I assume you really meant for either the
>>> constructor or this call to also take an Executor concept?
>> This line could be
>> boost::thread exec( ref(call) );
>> boost::thread_pool pool;
>> pool.dispatch( ref(call) );
>> I didn't have a prebuilt Boost.Threads library handy when I wrote
>> the code (rather quickly) so I used a plain call.
> No, it couldn't be, because async_call isn't copyable ;). But I get
> the point.
Note that I diligently used ref(call) above. ;-)
>> Since operator() is synchronized, i don't see a race... am I missing
> Sort of... I was thinking about the refactoring where you don't hold
> the mutex the entire time the function is being called. But even
> with out the refactoring, there is some room for error:
> thread1: call()
> thread2: call()
> thread1: result() // which result?
Unspecified, but I don't think we can avoid that with the low-level
interface. High level wrappers that package creation and execution would be
immune to this problem.
>>> Actually, there's another minor issue as well. The user can call
>>> operator() and then let the async_call go out of scope with out ever
>>> calling result(). Mayhem would ensue. The two options for dealing
>>> with this are to either block in the destructor until the call has
>>> completed or to simply document this as undefined behavior.
>> Yes, good point, I missed that.
> I lean towards simple undefined behavior. How do you feel about it?
Seems entirely reasonable. I don't think that we can "fix" this. Accessing
an object after it has been destroyed is simply an error; although this is
probably a good argument for making async_call copyable/counted so that the
copy being executed can keep the representation alive.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk