Re: Boost.Threads - thread_desc concept

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-06-30 13:05:05

> > Creation on the heap is orders of magnitude more expensive than
managing a
> > reference count.
> >
> > This is the major problem I see with a noncopyable design. [This is not
> > limited to the current discussion, but applies in general.] The design
> > forces the user to use 'new,' a keyword that has no place in user land.
>
> I agree strongly with this. The design should not force the user to call
> 'new'. I'd much rather see a copyable thread_id type.

i am really confused here. thread_id is simply
a pointer/ref/handle/.. to some native or non-native (C++)
thread _object_. id/ptr/ref/handle is copyable and
if needed could be extended with ref-counting so that
when the counter goes to zero it will either join thread
_and_ destroy thread object -- would simply call "delete"
(native thread object will be destroyed by join anyway)
or simply detach thread telling that thread object should
be destroyed  automatically on thread termination (in
this case it could be dangerous if detached thread would
pass self() id/ptr/ref/hndl to other threads - there is no
way to undo detach, well at least native detach).

thread objects are noncopyable (same as locks).
we have no direct access to native thread
objects -- the only access we have is via thread
ids/hndls. as for non-native (C++) thread objects
(built on top of native ids/hndls) -- sure you can
create them on the stack so that pre-destructor
would join [if not already joined explicitly] before
destruction or you can create them on dynamic store
and either manage it yourself via explicit or implicit
(ref-counting) "delete" (with optional explicit join
before delete) or via "detach" method (again it could
be trigger by ref-counter) telling thread object that
it should be automatically destructed on thread
termination.

static storage duration is an interesting case..
but as for thread ids/obj.ptrs/objects.. am i still
missing something?

regards,
alexander.