Re: Help with bumpless IOC reboot, record linking and initialization concepts

["Dmitry Yu. Bolkhovityanov via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Michael!

On Sat, 20 Sep 2025, Michael Davidsaver via Tech-talk wrote:

> On 9/19/25 00:35, Marco Filho wrote:
> >  Ah, I think I didn't properly understand this email on the first read.
> >
> > >  Generally, I have found that the more effective way to coordinate 
> > >  connect/disconnect is at the driver level.  Generally with a special 
> > >  device support to drive on-connect processing.
IMHO, it isn't a "more effective" but is rather the ONLY reliable way.

As only the driver code, which issues a connect() call and is directly 
notified about connect success or failure, thus has first-hand knowledge 
of the connection status and is able to perform connect/disconnect.
All the other ways use some form of side effects, which are unreliable 
and can change with time.
> >  You mean disconnecting from the actual equipment before the PVs are
> >  initialized and then only connecting once all the links are properly
> >  initialized?
> >  If so, how do you detect at driver level that that has happened?
> I think you have right idea, although the other way around.  My thinking is 
> that a driver initializes into a latched "error" state, which is cleared by 
> processing a record.  I like this approach because it naturally leads to 
> handling the initial connection the same as a re-connect.
For me it seems obvious to use 2 boolean PVs:

	1. "isConnected", which is SCAN="I/O intr" and is updated by the
	   driver upon change of connection state to be 1 (connected) or 0
	   (disconnected); initially value is 0.  (It can be naturally
	   monitored by code and DB links; multiple "isConnected" values
	   can be ANDed).

	2. "doConnect", which can be written to, =1 means "connect if not
	   connected" and =0 means "disconnect".

Isn't such a thing already done somewhere in asyn, streamDevice etc.?