Re: [Boost-build] Liking to pthreads

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.

Sure.

> > 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 
multi-threaded library?

> 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.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2