Towards the end of my tl;dr comment #18 above I wrote:
The solution to this probably has to involve reading the monotonic clock
and calling semTake(id, 1) again if the OS returned before the hi-res
delay has expired (we might have to do that twice).
So far I don't believe anybody has tried actually coding that fairly
obvious solution for any of the OSs where this problem exists.
--
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1861612
Title:
callbackRequestDelay not waiting for 1/60 sec on vxWorks
Status in EPICS Base:
Triaged
Bug description:
The problem is documented in this tech-talk thread:
https://epics.anl.gov/tech-talk/2020/msg00308.php
In 7.0.3.1, but not in 7.0.3, callbackRequestDelay(1/60) results in
100% CPU time, most of the time in cbHigh.
This happens on vxWorks 6.9.4.1 and was first seen with the scaler
record with multiple types of scaler hardware and device support.
To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1861612/+subscriptions
- Navigate by Date:
- Prev:
epics-7.0 - Build # 288 - Fixed! APS Jenkins via Core-talk
- Next:
Re: [Merge] ~jeonghanlee/epics-base:darwin-aarch64 into epics-base:7.0 Jeong Han Lee via Core-talk
- 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:
epics-7.0 - Build # 288 - Fixed! APS Jenkins via Core-talk
- Next:
Re: [Merge] ~jeonghanlee/epics-base:darwin-aarch64 into epics-base:7.0 Jeong Han Lee via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|