Le 11/10/12 22:48, Kim Barrett a écrit :
In boost 1.52.0 beta1
In boost/thread/pthread/once.hpp, near the head of the file, is the following conditional snippet:
#ifdef SIG_ATOMIC_MAX typedef sig_atomic_t uintmax_atomic_t; ... #else ... #endif
Well, sig_atomic_t may be a signed type, and in fact on the Linux system I'm testing on it is a typedef for int [suse12.1, but I suspect it doesn't really matter.] POSIX says "Possibly volatile-qualified integer type ...".
This led to boost::call_once never calling the function, because there is a comparison in call_once (epoch<this_thread_epoch) where I'm seeing values of 0 and -2 respectively for those variables, that doesn't go in the expected direction when uintmax_atomic_t is a signed type rather than the expected unsigned type. I bet there are other places that get confused by this being an unexpectedly signed type.
I'm working around this to continue my testing of 1.52beta1 by commenting out the offending conditional code and just using the code in the #else clause.
The relevant code is new code, introduced since boost 1.51. This is a serious regression that should be a blocker for the 1.52 release.
I've filed a bug for this: https://svn.boost.org/trac/boost/ticket/7499
Hi, this was part of a trial to fix https://svn.boost.org/trac/boost/ticket/5752. It seems that this was more disturbing than helping. As you can see on the ticket, I will use atomic<unsigned long> as soon as Boost.Atomic is part of the release branch. I will apply your patch as soon as my tests finish. Thanks for catching this before 1.52 is delivered, Vicente