Re: [boost] Re: Redesigned thread class

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-27 10:30:52

From: "William Kempf" <williamkempf_at_[hidden]>
> No.  Adoption is a QoI issue.  However, on most (obviously not all)
> platforms even if there's multiple libraries for MT they are all based on
OS
> level constructs so users expect the various wrappers to work together as
> much as possible.  Users will expect to be able to write library code that
> works no matter what MT library someone chooses to use in the application
> that links to it.  This is not an unreasonable expectation.  So a goal of
> Boost.Threads should be (and is) to make it as easy as possible for
> "adoption" to be implementable.  The proposed interface does this.
Adoption
> works flawlessly for both POSIX and Win32 implementations.  The thread_ref
> design, however, can't insure this, and in fact adoption on POSIX has been
> shown to be extremely problematic with this design.

Not 100% correct (AFAICS). This is not an inherent property of a
thread_ref-based design. The "implementation defined" current() means that
several different variations are possible:

1. Fully compliant, current() works as intended no matter what (requires
native support.) This is expected to be the behavior of a quality C++
standard library implementation that cooperates with the native threading
library if there is one.

2. (POSIX-based) current() works as intended provided that pthread_join()
and pthread_detach() are never called on an adopted thread.

3. (POSIX-based) current() works as intended except that an adopted thread
is not joinable; whoever created the thread is responsible for joining or
detaching it.

4. (Win32-based) current() works as intented, except that the thread object
associated with the adopted thread is not guaranteed to persist after the
thread_ref is destroyed. (Unless there's some clever way to implement
cleanup handlers on win32 that I'm missing. A __declspec(thread)+destructor
combo doesn't seem to work. A helper DLL might.)

And of course

5. current() cannot be used to adopts threads.

I should also add that when, in the future, thread cancelation is added to
the library, canceling an adopted thread would likely lead to undefined
behavior -- this applies to both designs. (Unless - again - I'm overlooking
a clever solution to the problem.)

> The complaint is that
> the proposed design makes a thread_ref design difficult to be implemented
on
> top of it, but my contention is that the issues are nearly identical to
> implementing a thread_ref design on top of POSIX to begin with.

Depends on which variation you have in mind. #2 is possible with pthreads
but not the current Boost.Threads, #3 is possible with both -- except for
the main thread problem with Boost.Threads.

> The one
> difference is a theoretical allowance for the "initial thread", but I find
> it very difficult to distinguish this thread from any other in this
regard.

Just to clarify, are you saying that Boost.Threads will never allow users to
join the main thread?

--
Peter Dimov
Multi Media Ltd.