[boost] Re: 1.30.0->1.30.2: no more thread support for Linux?

From: Ross Smith (rosss_at_[hidden])
Date: 2003-08-27 16:17:48

David Abrahams wrote:
> Ross Smith <rosss_at_[hidden]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Ross Smith <rosss_at_[hidden]> writes:
>>>
>>>
>>>>David Abrahams wrote:
>>>>
>>>>
>>>>>"Neal D. Becker" <nbecker_at_[hidden]> writes:
>>>>>
>>>>>
>>>>>>You mean I can't just run bjam with no options and get the libs
>>>>>>built with thread support?  I need to add a command-line option?
>>>>>
>>>>>The libraries that require thread support will be built with thread
>>>>>support.  The others will not, unless <threading>multi has been placed
>>>>>in their default-build settings; <threading>single is the global
>>>>>default.
>>>>
>>>>Which leads to three questions:
>>>>
>>>>(1) How do we do this?
>>>
>>>  Do what?  Get all multithreaded libraries automatically with zero
>>>user
>>>intervention on the command-line?  You convince the Boost developers
>>>who told me single-threading should be the default when I started
>>>Boost.Build that they were wrong, and I change the default.
>>
>>What the hell is the matter with you? 
> 
> I was a bit miffed by your outraged response to my explanatory reply.
> I thought I was being helpful and instead I got "when did you stop
> beating your wife?" questions like #2 and #3 below.  How is anyone
> supposed to answer those?

Well, I think we (Boost users) have a right to be annoyed at a hidden
gotcha as serious as this. Boost is built ST by default, and neither
that fact nor any way to change it is documented (in any place normal
users could reasonably be expected to look)? So we get non-threadsafe
code with no way of either knowing about it (until it crashes
mysteriously) or fixing it? That doesn't strike you as outrageous?

Boost includes a thread library, so I (and I expect every other user)
took it for granted that the rest of Boost would be threadsafe by
default. When the whole Boost library is built with a single command,
it would never in a million years have occurred to me that all the
parts might not use exactly the same options. That's just insane.

There's been this massive trap lurking in Boost all this time, and you
knew about it all along and didn't tell us. And you wonder why people
are pissed off??!!

>>All I asked was how to set the multithreaded option.
> 
> That question wasn't clear from your posting.  As far as I could tell
> you were asking how to "just run bjam with no options and get the libs
> built with thread support".  Maybe if you applied a little less heat
> it would be easier to help you.  Sarcastic rhetoric may have hurt the
> comprehensibility of your request.

It wasn't intended to be sarcastic, apart from the bit about
clairvoyance. The immediately preceding paragraph said "The others
will not, unless <threading>multi has been placed in their
default-build settings", so I thought it would be clear that that
was what I was asking how to do.

> http://www.boost.org/tools/build/build_system.htm documents how to
> set the build request on the command-line, and you can in fact find a
> mention of <threading>multi in there if you dig hard enough.

No, it only mentions threading in connection with writing new jamfiles.
There's nothing about how to set it on the command line. Presumably
somebody familiar with Jam could deduce one from the other, but I hope
you don't expect everyone who wants to use Boost to learn about Jam.

There's also no hint in there that the <threading>multi option has
anything to do with Boost; it's in the context of a hypothetical
project unrelated to Boost. So even somebody who did investigate how
to use the build system would have had no reason to suspect that
<threading>multi had anything to do with Boost. The option is not
mentioned anywhere else in the documentation. Neither are any other
options, for that matter.

And I still think my third question -- how many other gotchas are in
there? -- is a perfectly reasonable one. If you want me to spell it out
in more detail: What other undocumented build options are there that
might affect the library's behaviour?

-- 
Ross Smith ...................... Pharos Systems, Auckland, New Zealand
     "I virtually never go out of the house with less computing
     power on my person than the entire North American continent
     circa 1973." -- Charlie Stross