Re: V4 Design: Record Processing

[Tim Mooney <mooney@aps.anl.gov>]

Marty Kraimer wrote:
> Based on Tim's comments on my original proposal I completely rethought 
> and rewrote, with important input from Andrew, the proposed way to 
> handle record processing in V4.
> Tim,
>
> Are you subscribed to core-talk?
>
> Please read the new version and comment.
I liked most of the original proposal, and I'm not sure what the Wiki page
that replaced it is trying to say.  I don't understand how the PROC field,
a blanket command to process the record, is replaceable by a 'processState'
field, which seems not to be a command but merely a state indicator.  If it
is a command, I don't think it helps very much, because it would require an
outside agent to know too much about how the target record operates.  I don't
think we can guess in advance all the states a record might actually be in
anyway.

The original V4 Record Processing Wiki page had four really good ideas
that I believe would improve the plight of authors trying to code complex,
multistep algorithms:

1) A class of records that can block.

   I think almost half the code in the sscan record is devoted to bookmarking.
   In the middle of some algorithm, the record needs to wait for external
   events; the only way back in is process(), and so the record has to have a
   complicated arrangement of switches that get it back into the algorithm
   it was executing with enough state information to decide what to do next.
   At the same time, the record must check to see if it's now processing because
   of some out-of-band request from the user.  Normal and exceptional processing
   must, therefore, be mixed together in the switch arrangement, and adding
   new behaviors to the record becomes a very hairy undertaking.

   But what the record would really like to do is just wait with its context
   intact for events, and allow special() to release it from the wait if the
   user has requested something that requires this.  I guess this means the
   record should include author-defined event types in the wait mask, and
   special() should be able to generate author-defined events.

2) The notion that an input link can initiate processing, and get a value
   that is known to be the result of that processing, even if records to be
   processed are asynchronous in the V3 sense of that word.

   I think it's easy to underestimate the value of this capability.  It has
   far-reaching consequences, because a record that needs completion-qualified
   data will not have to know how to trigger the processing that generates
   that data, as it must in V3.  I think this is very clearly the right thing
   to do.

3) Support for a list of event types on which a record can wait.

   I would extend this to CA clients.  It would be nice if clients could
   say "send me all data that results from completed processing (even if the
   values are the same as last time), and send me only such data."

4) A link that can put, request processing, and wait for completion.

   We have this now in dbCaPutCallback(), but it's selectable only at DCT time.

-------------------------------------------------------------------------------

There is one other thing that I think should be included in record processing,
and this is also a channel-access issue:
Records can now respond to a client's request for field-specific drive limits,
display limits, precision, etc.  I think records should be able to respond to
a client's request for field-specific descriptions.  The .DESC field is just
not good enough.  Most record types currently don't have field-specific
descriptions to support this, of course, because there's no way they could get
the information to a client, but many record types could easily be modified
to benefit from it.

Absent any field-specific descriptions, a data-acquisition client can't put
the meaning of the data it has acquired into the data file, so the user has
to write a bunch of field-name/description entries into the file header --
for all the PV's that *might* be acquired.

--
Tim Mooney (mooney@aps.anl.gov) (630)963-1860
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.