Experimental Physics and Industrial Control System

Ok, so completely removing that "arbitrary" limit broke the code and
failed the timer tests because in libCom/timer/timerQueue.cpp Jeff
returns a timeout of DBL_MAX seconds when there are no active timers
registered on a queue, and that value gets passed to the
convertDoubleToWakeTime() routine inside epicsEventWaitWithTimeout()
which was somehow eventually resulting in a C++ exception (although we
do have a test for epicsEventWaitWithTimeout(event, DBL_MAX) which
doesn't fail on those systems, so I'm still missing something).

Last night I committed changes to make those time-out values 1000 years
in the future (~3.16e10 seconds), but that still failed on our older
linux-x86 (RHEL 6.x) and solaris-sparc build slaves since they can't
represent timestamps beyond 2038 using a 32-bit time_t. The code in
convertDoubleToWakeTime() (plus a few other places in libCom) was still
casting tv_sec values using (long) or static_cast<long> which I am
changing to time_t.

Eric: Would a 10-year timeout limit be acceptable? I can see 1 year as
being too short to represent forever, but to keep an IOC running for 10
years or more seems very unlikely to me.

My assumption is that Posix systems with 32-bit time_t will have all
been retired by 2028, although I will add tests that will fail on such
systems after that date. I will also undo my DBL_MAX changes in
libCom/timer.

- Andrew


On 06/07/2017 02:53 PM, Eric Norum wrote:
> Great!
> Thanks very much.
>> On Jun 7, 2017, at 12:33 PM, Johnson, Andrew N. <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> My guess is that the 3600 second timeout might have been thought of as
>> an arbitrary limit intended to avoid wrapping, but this is for the
>> Posix implementation only and I don’t see where such limits would
>> apply anyway. The convertDoubleToWakeTime() routine *only* appears to
>> be used in the Posix implementation of epicsEventWaitWithTimeout(),
>> and since the wakeTime is an absolute time anyway I think we can
>> safely remove the limit.
>>
>> I will do this in 3.14 and merge up, unless someone objects.
> 

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Navigate by Date:

Prev: Jenkins build is back to normal : epics-base-3.14-win64 #212 APS Jenkins

Next: Re: binding trouble if Port is already in use, src/ioc/rsrv/caservertask.c Heinz Junkes

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Jenkins build is back to normal : epics-base-3.14-win64 #212 APS Jenkins

Next: startPVAServer takes 15 seconds Mark Rivers

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024