Re: ASYN/devGPIB/GPIBCVTIO problem

[Andrew Johnson <anj@aps.anl.gov>]

Redman, Russell wrote:
> I am still not clear on the logic of the original behaviour.  If I want 
> to read a value from an asynchronous input record, and I do not care 
> whether it is up-to-date, I can use an NPP INLINK to fetch the current 
> value.  If I specifically ask for a PP INLINK, that surely indicates 
> that I need a completely up-to-date value and that stale data is 
> unacceptable.

The slightly strange behaviour probably stems from the addition of 
asynchronous processing to record support somewhat later than the design 
of the link API.  I'm guessing there as I wasn't involved when this was 
written and Marty is no longer 2 doors down from my office, but in any 
case I don't see an easy solution to achieving the behaviour that we 
would all like - it would require major surgery on the database 
processing code and all of the existing record types.

Reading a value through a link is an inherently synchronous operation in 
the current API - you call dbGetLink() and expect the result to be there 
as soon as the call returns.  If the link you're reading has its PP flag 
set, dbGetLink() calls the record's process routine first and then grabs 
the field value after it has returned.

Asynchronous record processing is by definition *not* a synchronous 
operation - you call the record's process() routine, and it will return 
almost immediately having started the I/O operation going.  There is no 
indication to the caller that it hasn't finished, although the caller 
could find out if it really wanted to by looking at the record's PACT 
field.  The I/O operation will finish at some point later (we hope!) and 
the associated device support will arrange for the record's process() 
routine to be called, after which the new engineering value is available 
to be read.

Reconciling the synchronous dbGetLink() call API with the asynchronous 
record processing behaviour would require that dbGetLink() not return 
until after the I/O operation has completed, which ties up the task that 
is doing the dbGetLink() operation - it can't return until it knows the 
value is available.  We don't know how long that will take though, it 
may be half an hour for some devices (extreme, but legal).  Since it's 
obviously not acceptable to suspend any of the existing scan tasks for 
that period of time waiting for one device to finish, we have to accept 
that the current design doesn't allow us to implement the behaviour we'd 
like for PP links to asynchronous records.  [Ben, if you think you have 
a working solution I'd love to see it.]

We can't change the record support asynchronous behaviour, so the only 
answer is to redesign the dbGetLink() API and make it asynchronous. 
That means using a new dbGetLinkCallback() call instead of dbGetLink(). 
 It also means that every routine that calls dbGetLink() would have to 
split into (at least) two routines, since everything which currently 
follows the dbGetLink() would have to be performed in a callback 
routine.  There are 49 such calls in src/rec, 7 more in src/db, and an 
unknown number in record types that are not shipped with base.

In the long term I'm sure we're going to want to resolve this issue, but 
I don't think it's particularly high on the priority list and there are 
other changes that we need to make to links which should be included in 
any change of this magnitude.

> Otherwise, why bother asking for PP?

If you don't ask for PP then (assuming the record has SCAN=Passive) it 
would never process so the I/O operation would never get performed at all.

- Andrew
--
* * Matt Santos / / For a Brighter America * *