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