Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 24 Feb 2005 12:22:43 +0100

On Thursday 24 February 2005 00:52, Andrew Johnson wrote:
> Proposal for V4:
>
> Change the way in which records are executed, allowing the database
> designer to select which threads perform processing of particular
> sets of records.

General comment: very good idea.

> In V3 we create a thread for each scan period, plus a number of other
> threads for callbacks etc. so the thread that a record processes in
> is vaguely related to its SCAN and PRIO fields.  I propose changing
> menuScan so it only contains "Passive", "Event", "I/O Interrupt" and
> "Periodic".  We add another field which is a double called scanPeriod
> which can be set to any period in seconds (this two-field approach is
> analagous to "Event" and the old EVNT field). 

The data type of the new scan specification is quite naturally expressed 
as an algebraic data type (=tagged union). In Haskell I would write

data Scan = Passive | Event Int | Interrupt | Periodic Double

In dbd syntax this could look like:

union(scanSpec) {
    choice(scanPassive,"Passive")
    choice(scanEvent,"Event") {
        field(event,octet)
    }
    choice(scanInterrupt,"Interrupt",)
    choice(scanPeriodic,"Periodic") {
        field(rate,float)
    }
}

(I took the freedom to allow leaving out an empty pair of braces "{}". 
This makes the union notation compatible with the one for menus, which 
are a special case of unions where all choices are tags only without 
data.)

One more comment on event scanning. Currently events are specified by a 
number between 0 and 255. This has many obvious disadvantages. I think 
for V4 we should consider supporting event identification by name, 
rather than number. The above would then become

union(scanSpec) {
    ...
    choice(scanEvent,"Event") {
        field(event,string)
    }
    ...
}

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System