[boost] Re: Boost.Threads: thread design

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-09-05 13:29:49

"William E. Kempf" wrote:
[...]
> In the mean time... I've found some issues with some of the ideas we've
> talked about.  The biggest among them is with providing a type safe return
> value when a thread is joined.  The proposal was to make the boost::thread
> type templatized on return type, but this causes serious problems with use.
> We no longer have a single thread type, but instead have an open ended set
> of thread types. ....

Unless you'll choose to settle on something along the lines of:

http://www.terekhov.de/thread_ptr.txt
(thread_ptr/joinable_thread_ptr/current_thread_ptr/new_thread()/etc.)

"....
 >// ---
 >// I was just thinking that to just store/compare different thread 
 id/ptrs
 >// it would be too prohibitive to require them to be of the same type
 >// (according to type of thread_routine return value). For example,
 >// it would significantly complicate/invalidate code which currently 
 stores
 >// and compares pthread_t objects. Basically thread_ptr is a C++
 >"equivalent"
 >// of pthread_t (but with extra NULL state, lack of witch is a real
 >problem/
 >// inconvenience in PTHREADS). Making thread::current() return 
 thread_ptr
 >// instead of current_thread_ptr would mean extra mutex locking... 
 might be
 >// OK, but given that I've used to FAST pthread_self(), personally,
 >// I have difficulties with this idea. On the other hand, I do not 
 see it
 >// as a critical issue.
 >// ---
 >// (The idea of current_thread_ptr is based on my experience that
 >programmers
 >// thread-share pthread_t objects obtained from pthread_self() rather
 >rarely. And
 >// since "self" ref is already counted in the "thread state", it is 
 ok NOT
 >to ref.count
 >// copies of it AS LONG as they are NOT shared with respect to other
 >threads.

 Correct as far as safety is concerned, but I still don't like the idea."

;-)

regards,
alexander.