Re: [Boost-bugs] [Boost C++ Libraries] #1268: xtime_cmp changes to deal with overflow were reverted

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #1268: xtime_cmp changes to deal with overflow were reverted
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2007-09-14 20:56:50

#1268: xtime_cmp changes to deal with overflow were reverted
-------------------------------+--------------------------------------------
  Reporter:  oseiler_at_[hidden]   |       Owner:  anthonyw
      Type:  Bugs              |      Status:  new     
 Milestone:  To Be Determined  |   Component:  thread  
   Version:  Boost 1.34.1      |    Severity:  Problem 
Resolution:                    |    Keywords:          
-------------------------------+--------------------------------------------
Comment (by oseiler_at_[hidden]):

 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.

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/1268#comment:3>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.