Re: Boost.Threads - thread_desc concept

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

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 
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...

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