Re: [Boost-users] [config][build] policy forsettingBOOST_HAS_THREADS?

Subject: Re: [Boost-users] [config][build] policy forsettingBOOST_HAS_THREADS?
From: John Maddock (john_at_[hidden])
Date: 2008-11-11 14:58:59

Vladimir Prus wrote:
>> I don't know if the current solution is right.

Nod.

BTW I didn't ask for the current situation, it was rather foisted upon us by 
the change to build and install a single binary.  We can fix up Boost.Config 
to behave any way we want, as long as everyone agrees! :-)

>> libstdc++ will work
>> no matter if your application is ST or MT -- where "MT" application
>> is defined as application that links to pthread and actually creates
>> multiple threads. But I think it's result of explicit work. In
>> particular:
>>
>>        - ABI is the same in ST and MT builds
>>        - if application is not linked to pthreads, then libstdc++
>>        will use dummy functions for synchronisation, with almost zero
>>        overhead.
>>
>> Boost, on the other hand, does not do anything special. The overhead
>> of locking does not go away if application does not use threads.

Unless we're also linking to the dummy pthread lib?  I thought that was what 
happened automatically on Linux at least anyway, unless you explicitly 
linked to -lpthread?

>> Therefore, it makes sense to control if that overhead exists -- by
>> explicitly controlling if Boost should be built in ST or MT mode, as
>> selected by 'threading' feature in Boost.Build or by -pthread
>> command line option in gcc.
>>
>> Just always building in MT mode is easy, but I don't know if that's
>> the best solution.

Nod.  As I say, just tell me what the solution is and we can go for it :-)

John.