Re: [Boost-build] Liking to pthreads

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-19 04:24:29

Vladimir Prus <ghost_at_[hidden]> writes:

> On Tuesday 19 September 2006 02:31, David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> >> >> There's far too much code now that's portable
>> >> >> only between Linux distros.
>> >> >>
>> >> >> I really think you should ask around on HPUX, AIX and *BSD groups,
>> >> >
>> >> > I'd go as far as say that if on any system, multi-threaded library
>> >> > can't be used by single-threaded application, it a bug.
>> >>
>> >> I think that's presumptuous.  It's easy to imagine an embedded system
>> >> where making that usage possible would induce overheads in the ST
>> >> application that the designers wanted to avoid.
>> >
>> > For example?
>>
>> Simple: errno always refers to something in TLS in a MT build, so
>> there's an extra level of indirection to access it.
>
> Ok, noted as point (1).

[Realized very late in this message:] OTOH you'd probably get a link
failure if not linking against the right runtime in that case.

>> > And which of operating systems above are embedded?
>>
>> Any of them, potentially.  Linux can be embedded.
>
> Embedded Linux is basically Linux running on "embedded" system, whatever it 
> is. There are not many differences.

Yes, but it doesn't take "many."  It just takes one system implementor
who decides to optimize.

>> And that is exactly an example of the potential problem.  If you pass
>> shared_ptr<T> across Boost.Python module boundaries and one is
>> compiled with MT enabled, you have an ABI change.
>>
>> I don't understand why you're so attached to avoiding mutexes in the
>> default case.  It's Boost.Python; we're typically getting a 1000x
>> speedup from using C++ instead of Python anyway, and there's a way to
>> avoid the extra overhead if you're really serious about it
>
> In point (1) above you argue that overhead of accessing errno via TLS can be 
> unacceptable. 

Yes, depending on context it may be.

> Now you're saying that the overhead of using mutexes is fine, 

Are you being purposefully combative?  

No, I am saying that it is *usually* fine, and especially so in an
application with Python bindings.

AFAICT the tradeoff is between an application that is sometimes slower
than desired and an application that sometimes crashes.  I'll take #1
and let people get speed by hook or by crook.  It seems you'll take #2
and let people get rid of crashes by hoook or crook.  I think that's
bad policy.

> and I think mutexes overhead is much larger.
>
> Note also that we're not talking about Boost.Python -- we're talking about 
> requiring all code that links to Python to be <threading>multi

Whatever; if it links to Python it probably can afford it.  And if it
can't, we can give people a way out.

>> (e.g. <undef>_REENTRANT or better, -<threading>multi).  My users can
>> tolerate that.  They can't tolerate hard-to-debug ABI conflicts.
>
> Well, I can modify python.jam, so that on all Unix-but-not-Linux platform, if 
> you try to use python target when threading != multi, you'll get the 
> following error:
>
>     error: the Python library on your system is multithreaded, but you
>     seem to be using it from a single-threaded program. It is possible
>     that on your system single- and multi- threaded libraries are not link
>     compatible, and the resulting application will not work.
>     You can either make all your application multi-threaded, or supress
>      this error by referring to python as /python//python/<threading>multi
>
> Would that be OK from your point of view?

Almost excellent.  "And the resulting application will not work"
understates the case too much.  It may have subtle and hard-to-detect
problems that only show up in the field.

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