Re: [boost] Re: Redesigned thread class

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-27 06:35:17

From: <williamkempf_at_[hidden]>
> > I see two other options.
> >
> > (1) "The behavior of current() invoked from a thread that has not
> been
> > created by create() and is not the main thread is implementation
> defined."
> >
> > (2) "A call to current() from a thread that has not been created by
> create()
> > and is not the main thread invokes undefined behavior."
>
> Both of which are just ambiguous equivalents of the first option I
> gave (indicate an error).  I don't expect that users will accept this.

They aren't "ambiguous equivalents of indicating an error."

(1) means that an implementation is free to make current() work (possibly
subject to some implementation-defined constraints, like prohibiting
pthread_join() and pthread_detach() calls on the adopted thread.)

(2) means that an implementation is free to NOT indicate an error.

> No, it's not under the control of the implementation. In neither
> Win32 nor POSIX does the implementation create the "initial thread".
> Even differentiating the "initial thread" from other threads is not
> really possible, short of using an "Init" class that's required to be
> instantiated in main(), or using a "thread_main()" alternate entry
> point, both of which are crude hacks that I'd rather avoid.

The misunderstanding here stems from my (unclear) usage of the term "the
implementation." I use the standardese meaning of the term. The main thread
is under implementation's control - it is the implementation that calls
main(), and handles dynamic initialization.

--
Peter Dimov
Multi Media Ltd.