Boost C++ Libraries: Ticket #1268: xtime_cmp changes to deal with overflow were reverted

oseiler@… — Fri, 14 Sep 2007 19:43:21 GMT

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@… — Fri, 14 Sep 2007 19:53:12 GMT

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@… — Fri, 14 Sep 2007 20:56:50 GMT

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.

status changed; resolution set

Anthony Williams — Fri, 23 May 2008 19:40:47 GMT

status new → closed
resolution → wontfix

xtime is deprecated in 1.35