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