Re: boost::thread::id()?

From: williamkempf_at_[hidden]
Date: 2001-09-24 15:44:05

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > From: <williamkempf_at_h...>
> > > > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > > > class thread
> > > > > {
> > > > >     unsigned long id() const; // uniquely identifies the 
thread
> > > > > };
> > > > >
> > > > > What do you think?
> > > >
> > > > I think it's a pain in the @$$ to implement on POSIX ;).
> > >
> > > I think that it's doable. You'd need a get_next_id() thread safe
> > function.
> >
> > Never said it wasn't doable.  In fact your solution actually 
existed
> > in earlier Boost.Threads code while I toyed with this method.  
There
> > are problems with this, such as the fact that it's at least
> > theoretically possible to exhaust all such id's if you don't track
> > which id's no longer have active threads.
> 
> int64_t? ;-)

Still has problems in theory, though it's not bloody likely that many 
(any) programs will cycle through all those ids.

> > You can't use a thread inside a std::map<> because it's not
> > copyable.  That's why I said I realized that there was not enough
> > functionality for collation but that there wasn't much need for 
it.
> > Even if we fully provided collation it's not useful for your
> > std::map<> because we can't copy it.  Wrap it in a thread::ref or 
use
> > pointers instead and you've "automagically" got a value that is
> > collatable... the pointer.
> 
> Not exactly because I don't have a way (within boost.threads) to 
obtain the
> pointer for the current thread; this can be worked around but this 
leads to
> a full-blown thread::ref anyway. ;-)

Well, yes, you're right about this issue.  I'm not sure how big of an 
issue it is, but you are right.

> > As for errorcheck mutex
> > implementations... you don't need full collation you only need
> > equality comparison, which boost::thread has already got.
> 
> But I need something to compare to. Are you suggesting that I store 
a
> boost::thread object inside the mutex, just for comparison 
purposes? Is this
> the 'official' Boost.Threads way?

Well, yes, that would be the current "official" Boost.Threads way.

Let me restate what my actual stance on this is, since it got glossed 
over with my reasoning for why it's not there today.  I see a lot of 
utility with a thread::id() and would like to see it's inclusion at 
some point.  I just want to leave it out initially since it's not a 
requirement for any real code (i.e. there are work arounds if it 
doesn't exist even if the work arounds aren't overly efficient).  
This will give me time to investigate a robust, portable 
implementation while not halting users from making use of 
Boost.Threads in the mean time.

I'll put this one on a higher priority list of todos that I'll tackle 
once Boost.Threads is officially in Boost, since you seem to have 
immediate need for it.

Bill Kempf