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
- Replies:
- Re: V4 Design: Record Processing Marty Kraimer
- References:
- V4 Design: Record Processing Marty Kraimer
- Re: V4 Design: Record Processing Tim Mooney
- Navigate by Date:
- Prev:
Re: V4 Design: Record Processing Tim Mooney
- Next:
Re: Record support and user-defined fields Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: V4 Design: Record Processing Tim Mooney
- Next:
Re: V4 Design: Record Processing Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|