Re: [boost] Boost.Thread

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-09-12 13:49:18

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
>operation
> > > > 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 join()ed
> > 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: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
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"