PV Condition Nodes | Store Value In Memory for Instanteous Return

[joshc-slac]

We can subclass condition nodes such that the boolean they are returning is stored in memory and we do not have to wait for a caget or other non zero return time process.

@ZLLentz has cool ideas about this with camonitor calls backs.

[ZLLentz]

Overall summary of the idea:

• BT consumer/executor process (server-side) reads the full tree and finds all the PVs to be checked
• The process monitors each PV with a callback to cache the result (+ alarm info)
• Check nodes get their values instantaneously from the cache rather than slowly via caget

[ZLLentz]

Timing-wise, the new values would come in on a background thread via the implementation of whichever CA library wrapper we use and this could technically be at an indeterminate time.

[tangkong]

We're not worried about stale values here? There's also definitely cases where we'll need to get fresh values (the case where one "do" routine has side effects on the system changing other system values)

[ZLLentz]

We aren't more worried about stale values for a monitor architecture since caget will also fail the same way if values are stale. For disconnected values both methods will let us know but caget will take longer.

Edit: we probably are worried about stale values in general regardless on our getting approach

The point about fresh values is very important. Do we need to build in some sort of smart waiting into the action nodes so they don't return complete until the related values update?

[joshc-slac]

While we definitely need to be worried about stale values this would give us the ability to determine what stale means.

Logging can capture the in memory conception of the value and we should have a lever that allows us to have some control of how frequently these values are polled (or updated via event)

[tangkong]

As long as we're sure that we're not just creating a place to store values only to reject them as stale most of the time or in the interest of safety.

This is starting to feel like premature optimization to me, how much of a lag do we expect from getting the value every time it's requested?

[ZLLentz]

Lag is a fraction of a fraction of a second if the PV exists, otherwise it's whatever our timeout is set to.

[joshc-slac]

To digest the above comments with slightly more perspective. Storing in memory may be less critical than having elegant code path should caget return None. This solution may then well be the same to "persisting" last cached value in memory. Potentially with timestamp...

[ZLLentz]

I'd caution against persisting old values- caget returning None implies that something is wrong with the IOC and should be an error state of some kind.

[joshc-slac]

Might want to consider not making this an MVP deliverable. Will put on the table for next BEAMS tagup (maybe we want to make that weekly if theres bandwidth?)