xtime_cmp changes to deal with overflow were reverted

[oseiler@…]

I'm running into this situation when specifying a very long timeout that winds up using boost::condition::timed_wait with an xtime value set up like so:

boost::xtime xt; boost::xtime_get( &xt, boost::TIME_UTC ); xt.sec += std::numeric_limits<uint32_t>::max(); ignore potential overflow, as sec is 64-bit condition.timed_wait( lock, xt ); <- this returns immediately

Traced this down to an overflow in xtime_cmp (boost/thread/xtime.hpp) that was fixed in version 1.14 of the file and reverted in version 1.15 of the file (replaced with the pre-1.14 version).

This is present in 1.33.1 (version being used on project) and in 1.34.1.

[oseiler@…]

Sorry about formatting; should have previewed. Here's the code fragment:

boost::xtime xt;
boost::xtime_get( &xt, boost::TIME_UTC );
xt.sec += std::numeric_limits<uint32_t>::max(); // ignore potential overflow, as sec is 64-bit
condition.timed_wait( lock, xt ); // <- this returns immediately

[oseiler@…]

Not sure what happened here, but everything I say above is wrong, except for the timed_wait behaviour; xtime.hpp didn't get reverted, the correct xtime_cmp is present in 1.33.1 and 1.34.1, and I appear to be unable to drive the web interface to the CVS repository.

boost::condition::timed_wait is returning immediately in the above situation, but my assessment is completely wrong.

[oseiler@…]

Working around this seems to indicate some underlying limitation of the boost implementation under Unix (1.33.1 running under SLES 10). By limiting xt.sec to numeric_limits<int>::max(), the timed_wait works correctly:

xt.sec += timeout; // timeout == numeric_limits<uint32_t>::max() in this case
if ( xt.sec > std::numeric_limits<int>::max() )
  xt.sec = std::numeric_limits<int>::max();

This works, though I suspect the actual cut-off point is greater than the max int as (max int + 1 ) and (max int + 2) also work, while (max uint32_t - 2) exhibits the problem. Probably related somehow to the Unix year 2038 problem... I'll probably work around this problem entirely by relying on condition::wait for an infinite wait, rather than abusing timed_wait in this way, but it would be nice to know what the limits are, given that at the xtime level I'm staying within the limits expressed by the type.

[Anthony Williams]

xtime is deprecated in 1.35