From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-30 11:24:52
From: "Peter Dimov" <pdimov_at_[hidden]>
>The main thread is significantly different from other 'adopted' threads
>assuming that such threads even exist. This is why it deserves special
>treatment.
>
>Every program has a main thread. Many (most?) programs don't have adopted
>threads.
I understand the reasoning and the concern. The problem is, the difference
is a very low level detail, part of the abstract machine, and the higher
level libraries (POSIX and Win32) we have access to (rightfully) hide the
differences and give us no way to differentiate the "initial thread" from
any other. So, from an implementation stand point for Boost.Threads, there
can be no difference. I expect the standards folks to address this issue,
however.
>The second reason that the main thread is not like the other adopted
>threads
>is because, for the other adopted threads, we assume that "whoever created
>the thread will join or detach it." This is not true for the main thread.
>We
>can offer full join support for the main thread.
We can still safely assume that "whoever created the thread will join or
detach it". There's no requirement in either POSIX or Win32 for user code
to "join" or "detach" the "initial thread". The abstract machine takes care
of this for you. You are right, however, that for both it's possible to
specifically "join" the "initial thread", and Boost.Threads has lost this
ability. I don't know how to safely and acceptably allow this, and find it
to be an acceptable loss. I really do feel that "joining" the "initial
thread" is a design error, and if one insists on such a design they can
accomplish it by having a "thread_main" that's the only thread spawned by
main().
I'm not arguing that the "initial thread" isn't a special case, I'm arguing
that given the implementation constraints that Boost.Threads has, it can't
treat it as a special case. The "initial thread" simply must be treated the
same as any other "adopted" thread.
>Without additional support from the runtime, the only requirement on the
>user code is that the first call to create() or current() (or the first
>attempt to construct a boost::thread) is made from the initial thread.
>Which
>is quite reasonable.
Well, I never thought of adopting the thread within create(). That does
make things seem to be "quite reasonable". Unfortunately, legacy libraries
can still cause holes in this if they spawn threads through native routines
and these threads call into routines that call current(). I may be able to
fill the holes in here... I haven't thought it through enough yet, but this
functionality simply isn't in the submission and I hope it's not enough of
an issue to warrant rejection (even on contingent changes) of the library.
This is an extreme corner case and we can address it in the future.
Bill Kempf
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp