Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-27 10:10:14

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <duncan_at_s...>
> > pdimov_at_m... (Peter Dimov) wrote:
> > 
> > > FWIW, I actually like procedural interfaces, when they fit. 
There is 
> > > nothing inherently low-level about them. thread::id may 
implement the
> > > handle/refcounted body idiom under the hood, or it may be a 
Win32 
> > > HANDLE. In a way, this interface is higher level, because it 
hides
> > > more of the implementation.
> > > 
> > > The important difference between thread::id and FILE* is that a 
FILE* 
> > > may leak. A thread::id can never leak. It has proper value 
semantics,
> > > so the 'thread reference' it contains will be released upon its
> > > destruction; and the thread will terminate itself when it's 
done.
> > 
> > Surely if the id is just a Win32 HANDLE then you have a leakage 
problem? 
> > Something has to close the handle to avoid a leak. If it were a 
Win32 
> > thread id that is not good enough because something must maintain 
an 
> > open handle to guarantee the thread id's uniqueness. So you are 
back to 
> > ref-counted handle-body and presumably the ref count must be 
thread 
> > safe.
> 
> You can let the OS do the counting:
> 
> 
> class thread_ref {
>    HANDLE id;
> public:
>    thread_ref(const thread_ref& r) {
>       if (!DuplicateHandle(GetCurrentProcess(),r.id,
>                            GetCurrentProcess(),&id,
>                            0,false,DUPLICATE_SAME_ACCESS))
>          throw something;
>    }
>    thread_ref& operator=(const thread_ref& r) {
>       if (&r != this) {
>          this->~thread_ref();
>          new(this) thread_ref(r);
>       }
>    }
>    ~thread_ref() { CloseHandle(id); }
> 
>    void join();
>    ...
> 
> };

Not all platforms can handle this in the same way, though, including 
pthreads.

Bill Kempf