Boost logo

Boost :

From: Bill Klein (bill_at_[hidden])
Date: 2001-06-27 09:33:43

Bill Klein wrote:
> > Because this function would return the thread_ptr, whose
> > destructor would detach() (this makes perfect sense: since the
> > last reference we had to the thread is gone, we can never access
> > it anyway, so detach the thread and let it do its own thing).
> > Alternatively you could have code such as:

williamkempf_at_[hidden] wrote:
> Careful. With a thread::self() method it *is* possible to obtain a
> reference to the thread even when all other references have gone
> away.

Ok, but why exactly is self() needed? I was thinking the methods you
can execute on thread_ptr were things like join and detatch which
obviously don't need to (can't!) be done by the thread itself... Also,
the implication of having self() is that there needs to be some
maintained list of references and stuff that gets messy... I'm sure
I'm just missing something, but I can't see why it's useful.

> I tried to address this in the current implementation, but I
> think there may be a problem in the way I handled this. What does
> pthreads define the behavior as if you don't detach (or join) a
> thread before the main thread of execution terminates?

I'm not positive, but I think any design that boost comes up with
shouldn't allow that to happen anyway, it's not clean... Using the
example I gave of create_thread() returning the reference-counted
handle would solve the problem, but as you say, having a self() might
complicate matters (though again, I'm confused as to what it's for).

> Natural for those of us used to other threading libraries. As
> pointed out by Beman's even asking the question, however, it's not
> necessarily natural for those very familiar with C++ design but not
> familiar with other threading libraries.

Understood. It seems to me that just having this very natural and
useful wrapper over existing C-style libraries would be very useful
regardless. Since it's so much simpler, a good interface could be
decided on more quickly, and later more interesting C++ thread
classes could be built on top of that if there's an interest. I'm
just scared that the boost thread stuff is turning into something
that I wouldn't use, and would have to revert to good old pthreads. :)

> In general this is just going to cause too many friend functions.
> I can see an argument for sleep() and yield() (though some
> platform may make these difficult to do with out access to the
> internal implementation of the thread class), but the others you'll
> have a harder time convincing me of.

Can you give an example of what functions would need to be friends of
the thread class? Don't forget that the main thread can call sleep()
and yield() as well, so that's a doubly good reason not to stick them
in the thread class...

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