Re: StreamDevice 2

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Ben

Benjamin Franksen wrote:

> I have one question: the docs say that readback from devices for output 
> records (for bumpless reboot) is done synchronously, blocking iocInit 
> until all such readbacks have completed. There may be situations where 
> this is the right aproach. However, there are others, where one would 
> wish to have the readback to proceed asynchronously, for instance if 
> there are a lot of such records on an IOC.
>
> In our MultiCAN package we do this by letting init_record 'fake' the 
> first phase of asynchronous processing. That is, init_record starts 
> readback, sets PACT and arranges for a special kind of process callback 
> that lets processing complete with a read (instead of the normal write) 
> operation.
>
> Would it be very difficult to enable such behavior (optionally, the 
> synchronous version remaining the default) for StreamDevice, too? Would 
> you accept a patch that implements this?

If you have many of such records, iocInit may take a long time. 
Initializing the records synchronously was the easiest way to ensure 
that all initialized records have got their values before any record 
processes and can ask for that value. (This is something I do not want 
to give up.)

I'll try to implement a more clever way to do this, initializing the 
records asyncronously ("in parallel") and then waiting in iocInit until 
all records have competed before the scan tasks start. If you send me 
some code example from your MultiCAN package, I will have a look at it.

> The StreamDevice docs mention the interaction with PINI flag. I think 
> the best solution is to enable readback on startup only if PINI 
> is /not/ set. Reading back from teh device hardly makes sense if the 
> first thing you are going to do is overwrite the value with something 
> else. OTOH, if PINI is not set, then doing a readback on startup will 
> at least not do any harm.

There is a conceptional difference between the @init handler and PINI. 
The first is initialization of the record (called from init_record()), 
the second is initialization of the device (called from process()).

Readback on startup is enabled if and only if an @init handler is 
defined (that reads the value). If you don't want a readback, don't 
define an @init handler. If you don't want to overwrite the value in the 
device, don't set PINI. I leave it to the user to decide if PINI after 
@init makes sense or not. Why should StreamDevice try to be smarter than 
the user? BTW: Maybe @init handlers do other stuff than readback, e.g. 
initializing the hardware. There is no simple way how StreamDevice can 
find out what @init actually does.

Dirk

--
Dr. Dirk Zimoch
Swiss Light Source
Paul Scherrer Institut
Computing and Controls
phone +41 56 310 5182
fax   +41 56 310 4413