Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-06-27 10:07:43

--- In boost_at_y..., Bill Klein <bill_at_o...> wrote:
> 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_h... wrote:
> > Careful. With a thread::self() method it *is* possible to obtain
> > 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...
> 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 addressed this in another post. Currently the need exists for
testing thread equality. Later additions may include the need for
changing a threads priority or...

> > 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()
> 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
> > 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. :)

I won't let that happen ;). But the Boost.Threads design may well be
the starting point of a C++ standard, so it must be done carefully
and can't be a quick "C++ wrapper around existing C-style
libraries". That's the impetus for this whole discussion. We need a
design that's C++ solid, yet is accessible to programmers used to
other threading libraries.

> > 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
> > have a harder time convincing me of.
> Can you give an example of what functions would need to be friends
> 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
> in the thread class...

You can't code create_thread() with out access to the internal state
information. The same goes for several other such methods. Like I
said, sleep() and yield() I can see an argument for, but the argument
won't apply universally.

Bill Kempf

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