$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: williamkempf_at_[hidden]
Date: 2001-08-25 16:50:24
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> 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. 
Bill Kempf