Re: [Boost-build] Liking to pthreads

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-18 09:52:52

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

because it gives a much more cogent explanation and describes what the
non-pthreads libraries are doing there.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com