From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-09-18 15:16:12
On Monday 18 September 2006 17:52, David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > On Thursday 07 September 2006 09:28, Vladimir Prus wrote:
> >> > > In what way is errno different?
> >> >
> >> > James wasn't allowed to post to this list, and I quite impolitely
> >> > forwarded his comments here, for which I have apologized. But he has
> >> > a point. Suffice it to say that he convinced me <threading>multi is
> >> > required in general, even if on many systems it can probably be left
> >> > out for many programs. Basically -mt has to be assumed to change the
> >> > ABI used by the standard library.
> >> The errno point is interesting.
> >> > So I think <threading>multi should be the default way to link with
> >> > pthreads, and the user should have to supply an explicit override if
> >> > she wants to live dangerously.
> >> I'll check with an expert, and get back ;-)
> > Finally done. I've talked with Daniel Jacobowitz who's close enough to
> > libc and binutils and gcc to just know things we tried to guess. I was
> > told that:
> > 1. For glibc and libstdc++, -pthread does not change any interface in a
> > link-incompatible way. On errno, specifically:
> >> errno always expands to (*__errno_location ()). Â Up until 2.2 or so,
> >> you could also say "int errno" and get the main thread's errno, without
> >> including <errno.h> - but it was a bug to do that.
> > 2. -pthread basically just sets _REENTRANT and add pthread to linker
> > command line. It does not cause any link-incompatibile changes itself.
> > 3. Any library can make link-incompatible changes in its interface when
> > _REENTRANT is defined, but that's up to each individual library.
> ...including any platform's standard or runtime libraries.
> > So, assuming we don't know about specific problems with Python, we should
> > assume it's safe to link MT libpython into single-threaded library.
> > I hope that's sufficient.
> It is certainly sufficient for glibc and libstdc++, but not for
> portable building on the "abstract machine."
Since abstract machine does not have any compiler options, or libraries, it's
not a useful point. At the moment we know that on gcc/libc of recent version,
things should work.
Do we know any other UNIXy system where single-threaded code can't call into
> However, unless James
> M. has some strong arguments to the contrary, I'm willing to go with
> the optimization as we currently have it. However, I would still like
> to replace the comment above the switch with:
> # Provide system library dependencies for static Python libraries.
> # Static libraries carry no library dependency information of
> # their own that the linker can extract, so library dependencies
> # have to be given explicitly on the link line of the client.
> # package the information into the "python" target below.
> # Even where Python itself uses pthreads, it never allows
> # extension modules to be entered concurrently (unless they
> # explicitly give up the interpreter lock). Therefore,
> # extension modules don't need the efficiency overhead of
> # threadsafe code as produced by <threading>multi, and we
> # handle libpthread along with other libraries here.
This sounds good to me.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk