From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-24 13:22:44
>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.
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk