Re: [boost] RE: Main thread

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-31 04:31:34

From: "William Kempf" <williamkempf_at_[hidden]>
> The "runtime" is a part of the abstract machine.

I think that you use a definition of the term "abstract machine" that I'm
not familiar with. The runtime library is not part of the abstract machine.
The abstract machine is an abstract model of a CPU; it executes the runtime
library (and any other code.)

> >Any dynamically initialized object with static storage duration will have
> >its initialization expression/constructor executed by the initial thread,
> >AFAICS. So the initial thread is very much detectable and 'special',
> >without
> >any modifications to the abstract machine.
>
> Ahh... but here's the rub.  You can't statically initialize a thread
> identifier.  In pthreads you have to call pthread_self() and in Win32 you
> have to call GetCurrentThread() in order to get the "current" thread
> identifier, and the minute you do this you're no longer in static storage
> duration.  When such data is initialized follows specific rules (which I
> know you're familiar with) and these rules do not gaurantee that they'll
be
> initialized by the "initial thread", and in fact under both Win32 and
POSIX
> you have no gaurantee what thread will initialize such data.

Static storage duration is not the same as static initialization, and I
specifically said "dynamically initialized object with static storage
duration" above.

You are correct that there is no guarantee that the dynamic intialization
will occur in the context of the initial thread, but the initialization
rules do imply a lot. The only scenario where dynamic initialization will
occur in the context of another thread (that is relevant to our problem) is
where

* dynamically initialized static object A creates a thread;
* the thread accesses an object B in a dynamically loaded library;
* the translation unit that contains B contains a static, dynamically
initialized object C.

C is now initialized -- most probably (nothing is guaranteed) -- within the
context of the other thread.

This issue will be fun to standardize. ;-)

Give me an implementation that ignores this issue and I'll be happy with it.
It'll work in 98% of the cases.

> But, again, I don't see this as much of a loss.  I strongly feel that it's
a
> design error to do this, and if you absolutely must do this you can
simulate
> it in user code any way.

I'm writing a thread_ref library. I don't have access to user code. ;-)

> Why does a thread_ref wrapper need to "join" main?

Why not? Orthogonality. All threads are equal (adopted threads don't count.)

> >Given the quality of your current implementation, I very much believe
that
> >you can overcome the technical problems. ;-)
>
> How.  Seriously, show me the error of my ways and I'll gladly change the
> design here in many ways.  If you can safely and completely adopt main,
> including the ability to "join" it, then I should be able to do the same
> with EVERY adopted thread and we can open up the design constraints a LOT.

No, I don't think that you can do the same with every adopted thread. That's
why I don't ask for it.

> >Besides, I don't ask for an implementation that works all the time. I ask
> >for a specification that calls for an implementation that works.
>
> I prefer an implementation that leaves as few holes as possible.  I guess
> you and I have different design goals in this regard.

I don't think so. Our main differences are that

(1) I think that the current thread design is neither low-level nor
high-level, meaning that it doesn't let me say

thread t(adopt_main_thread_please_I_take_the_responsibility); // post: t is
joinable

while at the same time it has more undefined behavior than I'd like.

(2) While I understand your position on the issues where technical reasons
with current thread libraries call for an interface that could have been
different were you designing a C++ standard library from the scratch, I
think that you can afford to move the line a bit. An 'approximation' to the
ideal implementation that works in 95% of the cases is good enough, as long
as it's possible to have a 100% implementation with the appropriate support
from the runtime.

--
Peter Dimov
Multi Media Ltd.