Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-06-22 11:06:26

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> Bill Kempf wrote:
> [ rationale for the current semantics, spread over three postings ]
> OK, I'm beginning to understand the rationale now. Let me extract
what I
> see as important from your messages and write it up as a Design
> section for the [currently named] class thread docs.
> >I'm more interested in the interface as well, but this is the
> >anyone's commented on it ;). The name may well be important here,
> >however. I understand Beman's argument and so I'm open to a name
> >change here... but a change to thread_handle, thread_id or
> >thread_desc, for instance, would necessitate a change to the
> >interface as well.
> Yes, I agree. One of my problems with the current design is that
as soon
> as I figured out that it was a descriptor/handle/id value class,
then the
> statics you mention below suffered the expectation problems you

Actually, the current design is a hybrid, which further adds to the
confusion. I'm swayed enough to think a redesign is needed, I'm just
not settled on which design is "better".

> > Some of the static methods make sense when the
> >class is named "thread", but not when any of these others are
> >chosen. The static methods sleep(), yield() and even create() and
> >self() are not actions one would expect to take on a
> >handle/id/descriptor to a thread, but are actions you'd expect to
> >take on the thread itself.
> Would there be a problem making them non-member functions? To me
> sounds clearer, although I'd have to look the final interface to be

Not necessarily, though it may complicate the implementation. Not a
good argument for maintaining the design, though, so...
> >Another suggestion would be thread_desc or thread_descriptor.
> Yes, those would work for me. Anything except thread. Even
thread_t would
> be enough name distinction to me. At least then in every email
> we wouldn't have to explain for every use of the word "thread"
whether we
> meant class thread or execution thread.

I'm still wondering if we shouldn't have two concepts here. The
thread class would remain much as it is now, except that it would not
be copyable and the create() method would return a thread_desc
instead of a thread. Again, this was the approach taken by J/Threads
and seems to be a nice compromise between the two designs being
discussed so far.

Bill Kempf

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