From: williamkempf_at_[hidden]
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
has the
> same effects/postcondition confusion in lots of places, but I
didn't
> 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
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.
I agree totally!
> >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 don't understand [1]. 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 [2]. With [2] 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 [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?
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
do the
> startup then shutdown). That way the semantics of join() wouldn't
have to
> 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?
Bill Kempf