John Maddock wrote:
Actually, I just don't want to pay for MT, unless I really mean to use the code in MT environment.
I understand that, but we have to decide how to handle this, so that it is actualy safe, and in particular boost headers should honor the compilers default setting.
I think I'm confused over what's "default setting" is, and if it important. I think the point is that 1. User should be able to specify if boost libraries should be thread-safe 2. He should do this with a minimum of effort. This is especially important for compile-only library So, if compiler has an option to tell if application should be build in MT mode, *that option* should affect thread safety of boost libraries. It's actually not very related to MT-safety of standard lib.
I don't really understand the problem. For example, are there any
compilers
which generate MT code by default? And, what's "default for the compiler"?
Yes, lots of them, MSVC when using a dll runtime,
Do you mean, when using /MD switch? But I believe default switch is /ML? So, there are two switches which mean "I'm building MT code": /MT and /MD, but none of those are default.
some Unix compilers I believe (though I forget which ones, can probably find out if it's important), gcc on some platforms as well.
Ok, on those platform we'd need to be thread-safe uncondionally.
Actually with gcc you already "pay" for threading support in the standard lib,
But that might be not so much, compared to say, locking in every place where shared_ptr is used in code.
likewise with MSVC, if you really want it turned off in Boost, then defining BOOST_DISABLE_THREADS will do the trick. What I'm trying to say is that our default behaviour should be the same as the compiler and std lib in use, any thing else will lead to confusion IMO.
Quite the contrary, I think we need to respect compiler switches, but not library settings. Anyway, this is only important if we can get gcc to reliable report -pthread presense.
This happens at the moment for example with MSVC where <runtime-link>dynamic implies <threading>multi, and any other option for the <threading> variant gets ignored.
And what's the problem with that?
You build the same library twice - for example with MSVC the <threading>multi<runtime-link>dynamic and <threading>single<runtime-link>dynamic variants are the actually the same thing (as far as the binaries are concerned), but both get built separately by a Boost install.
Ok, understood. - Volodya