Re: [boost] Re: Redesigned thread class

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-17 20:27:01

At 06:11 PM 8/17/2001, williamkempf_at_[hidden] wrote:

 >Agreed.  This brings up some questions about when to use
 >what "header" though.  So far we've used "Effects:" for a lot of
 >things that it appears the standard writers would have
 >used "Postconditions" for.

I was just looking at that in the standard last week.  The standard has the 
same effects/postcondition confusion in lots of places, but I didn't 
consider it worth defect reports.

 >  Hopefully we can work this stuff out
 >during review, as well as provide enough guidance in this regard so
 >that others can write documentation to this style with confidence :).

I'm not sure who developed the style, although it may have been Bill 
Plauger. It takes some getting used to, but is very precise.  I've 
switched  to it generally, and am quite happy. It would help both Boost and 
the standards committee if we can document it better.

 >Now, do the semantics sound usable?  What are the pros/cons of this
 >design compared to the original design?  Anyone strongly against my
 >switching to this new design?

Others understand the nuances better than I do, but it does seem a bit 
easier to grasp.

Please verify something for me.  Alexander quoted Dave Butenhof as saying:

 > But there were two problems. [1] There was no way to alter the
 > initial thread of a process so that its resources would be
 > automatically reclaimed on termination. [2] And there was this
 > nasty problem in join; where, if the join is cancelled,
 > which implies it didn't complete, the target thread of the
 > join would languish forever -- another memory leak about
 > which the program could do nothing.

Is it correct that your design does not have either of these problems 
because C++ semantics take care of [1], and [2] can't happen because there 
is no join cancellation?

I'm a bit worried about [1] in the case of a platform that had no native 
threading.  Wouldn't Boost.Threads then have to do some initialization work 
before starting the initial thread and some final work after the initial 
thread finished?  But if that happened, it would seem easier to require the 
initial thread be named something other than main (so main() could do the 
startup then shutdown). That way the semantics of join() wouldn't have to 
be messed with.

--Beman

--Beman