Boost logo

Boost :

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-09-12 14:05:33

When return values enter the picture, join needs to become the return value
accessor, allowed to be called more than once, and in parallel from multiple
threads. 'get' accessors are certainly const methods.

----- Original Message -----
From: Victor A. Wagner, Jr.
Newsgroups: gmane.comp.lib.boost.devel
Sent: Thursday, 2002:September:12 14:49
Subject: Re: Boost.Thread

At Thursday 2002/09/12 11:19, you wrote:
>From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> > At Thursday 2002/09/12 06:56, you wrote:
> > >From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> > > > Is thread::join () conceptually const? It seems like the kind of
> > > > that shouldn't mutate the thread, simply wait on it.
> > >
> > >It's also responsible for cleanup, but I guess that's not much of an
> > >argument for non-const usage only.
> >
> > I find it compelling, unless people want to allow a thread to be
> > more than once.
>You can delete only once, but that does not call for non-const pointers.
> > In that respect, I consider it almost exactly like
> > assigning auto_ptr<>s i.e. the source gets altered.
>I don't see the connection here.

when you assign an auto_ptr<> to another.... e.g.

x = y;

"ownership" of what is pointed to x, and y is altered (canNOT be const)

I was suggesting that the idea of being join()ing a thread should happen
only once... i.e. that the thread is "gone" after the join(). I found that
particularly important if results were being transferred (kinda like
auto_ptr<> the "source" doesn't have it any more)

>Bill Kempf
>Unsubscribe & other changes:

Victor A. Wagner Jr.
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at