Re: pC_->doCallbacksEnum() coming too early

[Ralph Lange via Core-talk <core-talk at aps.anl.gov>]

My 2cts. . . On Tue, 27 Feb 2024 at 23: 51, Mark Rivers via Core-talk <core-talk@ aps. anl. gov> wrote:   ZjQcmQRYFpfptBannerEnd Hi Torsten,   Ø  The PLC gives us some names for enmums, resulting in a call to Ø  pC_->doCallbacksEnum()   doCallbacksEnum()

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

My 2cts...

On Tue, 27 Feb 2024 at 23:51, Mark Rivers via Core-talk <core-talk at aps.anl.gov> wrote: 

ZjQcmQRYFpfptBannerEnd

Hi Torsten,

 

Ø  The PLC gives us some names for enmums, resulting in a call to

Ø  pC_->doCallbacksEnum()

 

doCallbacksEnum() is only intended to be called when an enum value changes at run-time, i.e. after iocInit.  For enums that the driver determines at initialization you should simply implement the asynPortDriver::readEnum() method.  Device support will call your driver during iocInit to read the enum values/strings/severities for all records with enum VAL fields.

 

testAsynPortDriver has an example here:

https://github.com/epics-modules/asyn/blob/a94a78987a99b1c36bbd641a67341069dc5d627e/testAsynPortDriverApp/src/testAsynPortDriver.cpp#L340

 

It also has an example of using doCallbacksEnum(), which it does when the vertical gain is changed at run time.

https://github.com/epics-modules/asyn/blob/a94a78987a99b1c36bbd641a67341069dc5d627e/testAsynPortDriverApp/src/testAsynPortDriver.cpp#L374

Been there...

The problem is that these are synchronous (blocking) calls. If you have many devices and/or devices that are handled asynchronously, this is likely to screw up your IOC startup.

I think the most reasonable way to handle the situation is a bit more complex:

• from the driver, do the requests to the devices as early as possible after the devices are up (and do the requests in parallel),
  
• when the responses come in, queue them,
• start the worker thread(s) for the queues (that push the values into the database) when the IOC is fully up, through the interruptAccept initHook.

That will work no matter if the IOC becomes ready before, during or after the initial device readout is finished.

Queueing incoming responses is always a good idea that helps with bursts or high-load-on-the-IOC-host situations.

Cheers,
~Ralph