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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-10 17:07:46

> From: David Abrahams <dave_at_[hidden]>
> "William E. Kempf" <wekempf_at_[hidden]> writes:
> >> > I lean towards simple undefined behavior.  How do you feel about it?
> 
> I have a feeling that I'm not being asked here, and maybe even that
> it's wasted breath because you've grown tired of my emphasis on a
> high-level interface, but there's a lot to be said for eliminating
> sources of undefined behavior, especially when it might have to do
> with the ordering of operations in a MT context.

No, I was asking anyone interested in responding, and you're certainly not wasting your breath.  I think I reached a compromise on these issues/questions, and would appreciate your response (it's in another post).
 
> >> 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.
> >
> > Yes, agreed.  I'm just not sure which approach is more
> > appropriate... to use dynamic allocation and ref-counting in the
> > implementation or to simply require the user to strictly manage the
> > lifetime of the async_call so that there's no issues with a truly
> > asynchronous Executor accessing the return value after it's gone out
> > of scope.
> 
> Allocation can be pretty darned efficient when it matters.  See my
> fast smart pointer allocator that Peter added to shared_ptr for
> example.

It's not just the efficiencies that concern me with dynamic allocation.  It's the additional points of failure that occur in this case as well.  For instance, check out the article on embedded coding in the most recent CUJ (sorry, don't have the exact title handy).  Embedded folks generally avoid dynamic memory when ever possible, so I'm a little uncomfortable with a solution that mandates that the implementation use dynamic allocation of memory.  At least, if that's the only solution provided.
 

William E. Kempf
wekempf_at_[hidden]