Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 12 Jul 2005 21:54:13 +0200

On Tuesday 12 July 2005 17:52, Tim Mooney wrote:
> 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.

I think the 'processState' is not to replace PROC (a command field) but 
rather to replace PACT (a status field). That is, the record's process 
routine decides what to do depending on the current processState. Thus, 
whenever record processing would want to suspend operation in order to 
wait for an event, it would set processState and return to the caller. 
It's a generalization of the way the PACT field is handled in V3.

Marty, please correct me if this is wrong.

> 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.

The problem with this approach is that you need a separate thread for 
each record instance of the blocking kind. Since EPICS uses the OS 
native threads, this is probably a bit too resource hungry for most 
systems.

So, instead of doing 'real' blocking, Marty proposes to temporarily 
suspend processing of an individual record by setting making it set the 
processState to something other than 'idle' and return, so that the 
core system can call process() again, whenever the conditions are 
appropriate (i.e. the events to wait for have happened).

The real question is whether a limited amount of predefined 
porcessStates is enough for all conceivable record types.

> 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.

This is still possibe with Marty's new proposal, if I understood it 
correctly. The same is true, I think, for your points 3 and 4.

> 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.

I think this is planned, more or less, at least the basic functionality 
will be in place. It depends on the record type, of course, for which 
fields it wants to publish detailed sub-properties. See 
http://www.aps.anl.gov/epics/wiki/index.php/V4_DBD_Statement_Syntax#view 
for details.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System