Good points.
I didn't think about external CA links, though.
As nowadays using CA/CP links is the only way to link records without
forcing them into the same lock set, it's a pity that this doesn't work
for PINI processing.
Idea: Why not introduce an additional PINI sweep, and change the PINI
field to be a three-option choice?
"NO", "YES", "UP": NO and YES yield the classical behaviour, while "UP"
puts the record into the second PINI phase, that runs *after* the CA
client and server are started (I.e., when the IOC is UP).
Should be compatible, shouldn't break existing stuff, allows CA/CP in
PINI processing.
For the Redundant IOC , it has the interesting side effect that you can
select if the record should be processed at boot time, or after the IOC
has become active.
(If the IOC switches back and forth between active and inactive, would
UP records be processed whenever it gets active? Do we need to
distinguish between "Once UP" and "Whenever UP"?)
Ralph
On 18.02.2009 16:59 Andrew Johnson wrote:
On Wednesday 18 February 2009 06:56:57 Ralph Lange wrote:
This sounds like a fix could be feasible and/or an issue on Andrew's
list, doesn't it?
Unfortunately I just realized that doing so would break the Redundant
IOC interface. Those xxxRun() calls are in iocRun() whereas the
initialProcess() call is in iocBuild(), so in a redundant IOC the PINI
processing happens at start-up but the CA links don't get connected
until the redundancy executive says "go" (which could be weeks or even
months later). I'm not sure if the initialProcess() call could/should
be moved, but doing so would change the meaning of some of our initHooks.
The other thing that worries me is that I think the act of connecting
up the CA links probably also enables any CP or CPP input links to
start processing, so it's possible that they could pre-empt the PINI
processing (especially if they're pointing at an external IOC which is
already running).
- Andrew
