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:
>// I was just thinking that to just store/compare different thread
>// 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
>// and compares pthread_t objects. Basically thread_ptr is a C++
>// of pthread_t (but with extra NULL state, lack of witch is a real
>// inconvenience in PTHREADS). Making thread::current() return
>// instead of current_thread_ptr would mean extra mutex locking...
>// 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
>// as a critical issue.
>// (The idea of current_thread_ptr is based on my experience that
>// thread-share pthread_t objects obtained from pthread_self() rather
>// since "self" ref is already counted in the "thread state", it is
>// copies of it AS LONG as they are NOT shared with respect to other
Correct as far as safety is concerned, but I still don't like the idea."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk