Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-28 12:52:49


I guess it depends on what "detach" means. I don't know pthreads, but
on Windows issue then is just , I think, whether to just close handle
in the destructor or wait for the thread to complete.

I think for the thread::ref doing a join() in the destructor would be
silly, what with many copies of the ref possibly spread all over the
program, but it might make sense for the thread destructor, assuming
there is even a thread class to have a destructor.

From: Jeremy Siek <jsiek_at_[hidden]>
>
> If the thread is going to be detached, why not just create it as detached
> from the start, instead of waiting until the destructor? I don't see how
> the lifetime of some thread ref object has anything to do with a detached
> thread.
>
> On Thu, 28 Jun 2001, Bill Klein wrote:
> > My programs tend to use other sync primatives as well and almost never
> > join... It seems to me that even in the case of programs where join
> > is used, it will tend to be an explicit call at a specific place (i.e.
> > not just when the last reference to the thread disapears!). I think
> > detach is the proper 'default' that should happen in the destructor if
> > join (or detatch) are never called explicitly.
> >
> > (Another reason is that join can take a long time [of course] and I
> > like to keep destructors quick and simple, but maybe this is not a
> > valid reason).
> >
> > - Bill
> >
> >
> > Info: http://www.boost.org Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> ----------------------------------------------------------------------
> Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
> Ph.D. Candidate, IU B'ton email: jsiek_at_[hidden]
> Summer Manager, AT&T Research phone: (973) 360-8185
> ----------------------------------------------------------------------
>
>
>
> Info: http://www.boost.org Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk