From: David Abrahams (dave_at_[hidden])
Date: 2003-02-10 13:09:25
"Peter Dimov" <pdimov_at_[hidden]> writes:
> 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.
Is there really a need for a low-level async_call interface? After
all, the existing threads interface provides all the low-levelness
you can handle.
>>>> 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.
Seems like this is also pointing at a high-level interface...
-- 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