Re: [boost] Re: Redesigned thread class

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-25 18:00:13

From: <williamkempf_at_[hidden]>
> > From: <williamkempf_at_h...>
> > > I've explained this before.  When linking with other libraries 
> (both
> > > C and C++) it's quite possible that the library has created 
> threads
> > > using the "native" means, POSIX in this case.  These libraries can
> > > call back into code that calls boost::thread() (or 
> equivalent "self"
> > > functionality).
> > 
> > Yes, I understand that. My question was, why do you consider this a 
> major
> > issue? Will users expect that, in a situation like the above --  a 
> callback
> > invoked from a library that uses native threading -- they ought to 
> be able
> > to use Boost.Threads functionality? How common would this situation 
> be?
> 
> I expect it would be fairly common.  There's no hard evidence, though 
> it seems "obvious" to me.
> 
> > > At this point the thread must either be adopted, or
> > > you must indicate some sort of error, and the only option that's
> > > likely to be acceptable to users is to adopt the thread.
> > 
> > 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.
>  
> > > Even
> > > the "initial thread", as you've pointed out, is a thread created 
> from
> > > outside of Boost.Threads and so a thread that must be adopted.
> > 
> > The initial thread is an exception. It is under the control of the
> > implementation, whereas threads created by a third-party library 
> calling
> > pthread_create() are not.
> 
> 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 main() routine is under the control of the implementation
in the sense that the implementer writes it, can so do whatever
is needed to be sure the initial thread can be adopted, if we
insist that it must.

Consider platforms with more than one threading API, does the
implementer have to support them all?

Consider platforms with no threading API, where the implementor
chooses to use processes and shared memory to implement (pseudo)
threads, and there are also other libraries for the platform that
do something similar.  Do the other library's "threads" need to
be adoptable?

Consider implementations that choose not to use native threads.

Consider too many other possibilities to keep typing ...

So I am quite happy with "implementation defined".