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.