Re: [boost] Boost.Threads - Final Design Decisions

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-18 11:37:24

> A noncopyable thread object _is_ a perfect fit
> for the thread concept if you can guarantee that
> there is one to one correspondence between the actual
> threads and the C++ thread objects.

agree.

> Such a design is possible:
>
> thread & create(F f);
> thread & current();
>
> [where current() called from within 'f' would
> return a reference to the same thread object as
> create().]

i think that the following is also possible:

thread mythread( f );

[where current() called from within 'f' would
return a reference to mythread thread object]

e.g. 'local' threads (pseudo-code):

t f1( .... );
t f2( .... );
t f3( .... );
const t& select( const t&,const t&,const t& );

// single-threaded
t fst( .... )
{ return select( f1(....),f2(....),f3(....) ); }

// multi-threaded
t fmt( .... )
{ return select( thread( f1,....),thread( f2,....),thread( f3,....) ); }

here select function could be invoked as soon as all
threads would report their return values... with the
rest/most of threads termination done concurrently with
respect to select execution... (final "join" cleanup/
synch done on local thread objects destruction)

> Unfortunately, without garbage collection, the references would become
> invalid when 'f' returns (without warning.)

why? for "joinable" threads when f returns, nothing terrible
(with respect to thread objects - C++ and/or native) really
happens.. only "join" would explicitly destroy native thread
object (after awaiting thread termination, implicit destruction
via "detach" aside; IMHO that should only be done for dynamic
C++ thread objects; btw native thread objects (represented by
pthread_t/HANDLE) are always dynamic).

regards,
alexander.