V4 Design: Record Processing
EPICS V4: Record Processing
July 06 2005
Overview
NOTE: The comments from Tim Mooney about my previous thoughts on V4 record processing show that what I proposed will not work. This is a new proposal for V4 record processing.
Lets first state some goals for linking to other records:
- Input Links - This means input from sources outside the record.
- get current value
- process record then get value
- wait until next process then get value
- Output Links
- put value
- put value then process record
- put value then process record and wait for completion
For both input and output links Application Developer should be able to specify the following options for asynchronous links:
- Allow simultaneous requests
- processon link at a time.
This is done separately for input and for output links.
Processing States
Instead of the V3 PROC field, V4 will have a field processState. This field will have the states:
- idle
- record is not being processed
- baseInputActive
- iocRecord is waiting for input to be done
- baseInputDone
- iocRecord has completed all input
- usetInputActive
- user defined fields are active.
- userInputDone
- user defined fields are done.
- inputActive
- input link processing is active
- inputDone
- all input links have completed
- deviceActive
- device support is active
- deviceDone
- device support has completed
- active
- record support is waiting for something to complete
- activeDone
- record support has completed all record related processing
- outputActive
- record support is waiting for output links to complete
- outputDone
- all output links have completed
- baseOutputActive
- iocRecord is waiting for input to be done
- baseOutputDone
- iocRecord has completed all output
- userOutputActive
- user defined fields are active.
- userOutputDone
Some comments:
- iocRecord is what is called dbCommon in V4. For V4 it will have associated record support that will handle all the fields in iocRecord including an array of forward links. It will handle record completion.
- Each state may have substates. For example if a record has multiple record specific input links that are to be processed sequentially, it can keep state describing which link is being processed.
- Individual record types may have only a subset of the above states.
dbProcess
dbProcess does the following based on state:
- idle
- call iocRecord:process, which will handle all the input fields in iocRecord.
- baseInputActive
- nothing
- baseInputDone
- starts a loop to call process for each user defined field
- usetInputActive
- nothing
- userInputDone
- If not done with user fields continue loop. When user fields are done calls RecordSupport:process
- inputActive
- nothing
- inputDone
- nothing. Let record support decide when it is done
- deviceActive
- nothing
- deviceDone
- nothing
- active
- call RecordSupport:process. It can do what it wants.
- activeDone
- nothing
- outputActive
- nothing
- outputDone
- call iocRecord:process
- baseOutputActive
- nothing
- baseOutputDone
- starts a loop to call process for each user defined field
- userOutputActive
- nothing
- userOutputDone
- If not done with user fields continue loop. When user fields are done post monitprs for record done. Set state to idle.
Some comments:
- It has to be determined who/what calls dbProcess
- It has to be decided when to post monitors. Tim's comments show that monitors can be issued while a record is active. These are different than monitors at the end of record processing.
Notification of Process Completion
The request to process a record can specify a callback that is called when the record completes processing. It is also possible to make a process callback request over the network.
Alarm Processing
Are changes needed from the V3 model?
Posting Modifications
Whenever code modifies a field that is acessable outside the record it must call ????
When record support wants the modifications to be made available to code that has set monitors on fields in the record it calls ???
