[Bug 1841634] Re: CP link triggers lost when record is async

[mdavidsaver via Core-talk <core-talk@aps.anl.gov>]

> Okay, so that part of dbCa changed in 3.16 without my realizing it

cf. https://code.launchpad.net/~epics-core/epics-base/dbscan-
update/+merge/245680

I hide it right at the top of the diff?

> I see little point in processing the record more than once

Fine with me.  I can't recall where the 5 times came from.

> modify onceTask to give it a more general callback mechanism

In terms of complexity, this seems not far away from callbackRequest().
Why not just use that?  This would also have the side effect of making
.PRIO meaningful for CP links.

-- 
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/1841634

Title:
  CP link triggers lost when record is async

Status in EPICS Base:
  Confirmed
Status in EPICS Base 7.0 series:
  Confirmed

Bug description:
  From Benjamin Franksen:

  Here is a small self-contained database to reproduce this:

  record(calcout,"input") {
      field(CALC,"A<4?A+1:A")
      field(INPA,"input")
      field(ODLY,"1")
      field(OUT,"input.A CA")
  }
  record(calcout,"output") {
      field(ODLY,"1.5")
      field(INPA,"input CPP")
      field(CALC,"A")
      field(TPRO,1)
  }
  record(calc,"check") {
      field(INPA,"input CPP")
      field(INPB,"output CPP")
      field(CALC,"A==B")
  }

  Processing "input" (caput input.PROC 1) starts the test. The "check"
  record should eventually settle to 1 (but doesn't).

  With 7.0.3 I get this output:

  scanOnce: dbProcess of 'output' # initial CPP processing
  scanOnce: dbProcess of 'output'
  scanOnce: dbProcess of Active 'output' with RPRO=0
  scanOnce: dbProcess of 'output'
  scanOnce: dbProcess of Active 'output' with RPRO=0

  Note how this says "with RPRO=0".

  And camonitor says:

  franksen@tiber: ~ > camonitor input output check
  input                          <undefined> 0 UDF INVALID
  output                         2019-08-27 16:02:16.106413 0
  check                          2019-08-27 16:02:16.106617 1
  input                          2019-08-27 16:02:26.498483 1
  check                          2019-08-27 16:02:26.498721 0
  input                          2019-08-27 16:02:27.493734 2
  output                         2019-08-27 16:02:27.993908 1
  input                          2019-08-27 16:02:28.489068 3
  input                          2019-08-27 16:02:29.484350 4
  output                         2019-08-27 16:02:29.984458 3

  I think the difference in behavior between processing due to a CPP
  input link versus processing due to a PP or CA output link is quite
  surprising.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1841634/+subscriptions