Experimental Physics and
| |||||||||||||||||
|
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 * *
| ||||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |