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
> > C and C++) it's quite possible that the library has created
> > using the "native" means, POSIX in this case. These libraries can
> > call back into code that calls boost::thread() (or
> > functionality).
> Yes, I understand that. My question was, why do you consider this a
> issue? Will users expect that, in a situation like the above -- a
> invoked from a library that uses native threading -- they ought to
> to use Boost.Threads functionality? How common would this situation
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
> created by create() and is not the main thread is implementation
> (2) "A call to current() from a thread that has not been created by
> 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
> > 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk