Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-24 13:55:49

Thanks for clearing this up. The discussion of default contructors,
adopted threads, and join semantics is beyond me right now, and I
haven't time to study it, what with deadlines looming at work (we
have to clear all our outstanding bugs by Sunday night, and we have
to write a new JIT compiler by Nov 15). So I'll be satisfied if,
however it works out, there is a clear discussion of the issues in
the documentation, with rationale for the final choices.

From: William Kempf <williamkempf_at_[hidden]>
> >I prefer the thread::ref design, but I wouldn't reject your (excellent)
> >work on that basis. It is clear that your design is a good one for a
> >broad range of uses, and I want to accept it.
> >
> >I've lost track of the discussion recently, and my copy of the docs is
> >dated Aug 1, so let me just ask some questions to catch up:
> The latest proposal was never checked into CVS since it added a lot of
> restrictions on usage that I thought may be controversial. However, they
> vastly simplify the implementation, are much closer to POSIX specifications,
> etc. So I may go ahead and check it in any way so that people can look
> directly at the docs/implementation. There's definately controversy on the
> design, hence this particular query, but given the time constraints and the
> issues with other designs...
> >1) Is there a function that returns a pointer or reference to the
> > boost::thread object for the thread that it is called on? If not,
> > why not? If so, what does it do if the thread object is gone?
> No, but there's a default constructor that achieves the same purpose. Like
> other C++ resource wrapping designs such objects can outlive the lifetime of
> the wrapped resource, but the set of valid operations become very
> constrained at that point (basically to the point where the only valid
> operation is destruction in our case).
> >2) Do we know that shared_ptr<thread>(new thread(func)) will suffice
> > for memory management? If not, why not?
> Accept for "join" semantics with regards to adopted threads, yes we're sure.
> >3) If shared_ptr is unworkable or inefficient, are there any obstacles
> > to introducing thread::ref in the future?
> The issue is squarely with "join" semantics for adopted threads.

Boost list run by bdawes at, gregod at, cpdaniel at, john at