Re: Boost.Threads - name of the "thread" type

From: williamkempf_at_[hidden]
Date: 2001-06-22 09:27:56

--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> Greg Colvin wrote:
> > 
> > For threads the typical use is to spawn a thread and forget
> > about it, with the expectation that it will do whatever it
> > needs to do and go away on its own when it is done.
> 
> That's a _very_ dangerous strategy!

Actually, it's not, and Greg is correct this *is* a very common 
strategy used.

> If main() exits first, the thread
> gets stabbed in the back (at least on Unix -- I think Windows keeps 
the
> process alive as long as there are any threads still running). 

No, on both platforms the child threads are destroyed.

>Granted
> there are times when you want to do that, but I certainly wouldn't 
call
> it the _typical_ use.

I'd say both strategies are used with the same amount of frequency.

> > Yes, and that might be one way to solve it.  I think the catch
> > is that if you have created a thread and retained no references
> > to it you may want it just go away when its function exits.
> 
> It sounds as though you're assuming that the object's lifetime must 
be
> the same as the thread's lifetime. I don't think that's necessary; 
just
> call pthread_detach() in the destructor if the thread hasn't been 
joined
> yet (under pthreads; on Windows it doesn't matter, you just call
> CloseHandle() regardless).

This defines semantics that are atypical, and to my mind they are as 
misleading as using reference semantics while retaining the 
name "thread".

> (Then again, possibly I'm not the best guy to be putting his oar in 
at
> the moment; I'm not very keen on what I've seen of the Boost threads
> library so far, so clearly your aims are different to mine.)

Then your opinions are the opinions I most want to hear.  Why are you 
not keen on what we have so far?

Bill Kempf