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