Boost logo

Boost :

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
> > > > > };
> > > > >
> > > > > 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
> > in earlier Boost.Threads code while I toyed with this method.
> > 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
> > 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
> > 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
> 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

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