On Wed, Nov 22, 2006 at 09:54:42AM -0700, Shaun Jackman wrote: > On 11/22/06, Roman Zippel <[EMAIL PROTECTED]> wrote: > ... > >> 1. Is this more likely a bug in Boost or a bug in monotone? > >> 2. Is it reasonable to workaround this bug by removing > >> -DBOOST_SP_DISABLE_THREADS? > >> 3. Is it worth going to the extra effort to only define > >> -DBOOST_SP_DISABLE_THREADS on the platforms for which it works? I'll > >> consider this last option if it means a performance improvement of at > >> least, say arbitrarily, a factor of two or so. > > > >I think this should include the boost maintainer, there has to be some way > >to safely select the proper compile flags. At least the Debian packages > >provide a threaded and non-threaded version, but the .so link points to > >the threaded version by default. > >If both versions are supposed to be usable equally for non-threaded > >application it suggest a bug in boost... > >Anyway, until there is some mechanism to select this safely, it's probably > >better to compile the application with the same flags as the library was.
Right -- I tracked down the official word on this, which says: "If your program is single-threaded and does not link to any libraries that might have used shared_ptr in its default configuration, you can #define the macro BOOST_SP_DISABLE_THREADS on a project-wide basis to switch to ordinary non-atomic reference count updates. "(Defining BOOST_SP_DISABLE_THREADS in some, but not all, translation units is technically a violation of the One Definition Rule and undefined behavior. Nevertheless, the implementation attempts to do its best to accommodate the request to use non-atomic updates in those translation units. No guarantees, though.)" ( http://www.boost.org/libs/smart_ptr/shared_ptr.htm ) So basically, if a program uses boost::shared_ptr, and also uses libraries that use boost::shared_ptr (including other boost libraries), then your program and those libraries must be compiled with the same BOOST_SP_DISABLE_THREADS setting. Unless you get lucky. (I guess it failing on less popular platforms in particular has something to do with the workarounds they mention in the second paragraph?) > I'll probably make an upload today. So, to be sure, I'm going to > remove -DBOOST_SP_DISABLE_THREADS, but leave -DBOOST_DISABLE_THREADS? > Is that correct, or are both defines to be removed? That sounds correct. I suspect the reason _SP_ is split off as its own thing is exactly this... -- Nathaniel -- "The problem...is that sets have a very limited range of activities -- they can't carry pianos, for example, nor drink beer." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]