Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk