RE: Main thread

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