You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/* I thought this would be a temporary fix until EPICS supported PINI after interruptAccept, which would then be used
* for input records that need callbacks after output records that also have PINI and that could affect them. But this
* does not work with asyn device support because of the ring buffer. Records with SCAN=I/O Intr must not processed
* for any other reason, including PINI, or the ring buffer can get out of sync. */
In all likelihood, the hang I am seeing is due to me having missed some preparation. Still, I thought it worth asking. Is the special handling of interruptAccept is still needed? Can some nicer solution can be found? (maybe involving registrars and initHooks)
I came across this comment while trying to understand why a plugin unittest I am trying to write hangs on exit in
callbackThread::~callbackThread()
.asyn/asyn/asynPortDriver/asynPortDriver.cpp
Lines 919 to 922 in db991c2
In all likelihood, the hang I am seeing is due to me having missed some preparation. Still, I thought it worth asking. Is the special handling of
interruptAccept
is still needed? Can some nicer solution can be found? (maybe involving registrars and initHooks)fyi.
The
field(PINI, "RUNNING")
was added by epics-base/epics-base@68dbf8a in epics-base 3.14.11 back in 2009.The
initHook
API moved into libCom in 7.0.2 (epics-base/epics-base@dc310a4).The text was updated successfully, but these errors were encountered: