Date: 2001-08-18 07:44:04
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 06:11 PM 8/17/2001, williamkempf_at_h... 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
> same effects/postcondition confusion in lots of places, but I
> consider it worth defect reports.
I wouldn't either, but it would still be nice to have this documented
so that future documentation can be written with confidence.
> > Hopefully we can work this stuff out
> >during review, as well as provide enough guidance in this regard
> >that others can write documentation to this style with
> I'm not sure who developed the style, although it may have been
> 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
> the standards committee if we can document it better.
I agree totally!
> >Now, do the semantics sound usable? What are the pros/cons of
> >design compared to the original design? Anyone strongly against
> >switching to this new design?
> Others understand the nuances better than I do, but it does seem a
> easier to grasp.
> Please verify something for me. Alexander quoted Dave Butenhof as
> > But there were two problems.  There was no way to alter the
> > initial thread of a process so that its resources would be
> > automatically reclaimed on termination.  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
> because C++ semantics take care of , and  can't happen
> is no join cancellation?
I don't understand . Seems to me that even in C an atexit()
routine could be used to insure this. However, it's probably a minor
technical issue related to . With  you've missed the context
of the quote. He meant that these problems occurred when they
removed pthread_detach(), and so pthread_detach() had to be re-
added. Boost.Threads does include "detach", via the destructor, so I
don't think we have a problem here even when we add cancellation.
> I'm a bit worried about  in the case of a platform that had no
> threading. Wouldn't Boost.Threads then have to do some
> before starting the initial thread and some final work after the
> thread finished?
After, yes. We'd need an atexit() routine. However, this routine
can be "lazy initialized" so there's not a real need for doing
anything prior to main().
> But if that happened, it would seem easier to require the
> initial thread be named something other than main (so main() could
> startup then shutdown). That way the semantics of join() wouldn't
> be messed with.
Now, we should make sure that I interpreted this all correctly.
Alexander, do you see any issues here related to any of this?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk