Re: [boost] Re: Review: Boost.Threads

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-18 06:28:20

From: <williamkempf_at_[hidden]>
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > IOW join() invalidates the object. The only allowed operation is
> > destruction. Everything else invokes undefined behavior.
> >
> > I can live with such a join. However I think that an equally viable
> > alternative is a join() that doesn't invalidate. I don't see what
> is gained
> > by making access to a joined thread undefined behavior.
>
> The only resource that could still be left around is the "thread id",
> so the only operation that could still be valid is comparison.  All
> other operations would be invalid simply because there's no thread of
> execution left on which to operate.

I don't see why. Let's assume a pthread back end. The only resource that is
invalidated by pthread_join is the pthread_id (direct opposite of what you
said.)

Nevertheless, it's perfectly possible to make 'join' work even on a thread
that has been already joined. It would simply return.

Again, I don't see what the undefined behavior buys us. POSIX has reasons to
do things this way, since it's a C API, with one constructor -
pthread_create - and two destructors, pthread_join and pthread_detach. But a
C++ object can't have two destructors, so retaining the exact pthread_join
semantics is not - IMHO - appropriate.

--
Peter Dimov
Multi Media Ltd.