Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Wed, 19 Oct 2005 07:44:52 -0500

Ralph Lange wrote:

Marty Kraimer wrote:

Before starting on benjamin's message in details I do like "asyn"

instead of "wait".

But perhaps callback is even better with callback=true meaning that

link support will call a callback when the link completes. Either

asyn or callback is better than wait.

I don't like "callback" or "asyn" at all as they are clearly pointing

to /implementations/ of a mechanism.

The database designer should configure /what/ should be happening, not

/how/ it is achieved.

OK.  None of callback, asyn, or wait is a good name. Any other ideas?
Also is there a better word than  block?

For now I will still use block and wait but see below for the meaning of

block

The proposal to have just

process - boolean, i.e. should request be made to process record

wait - boolean, i.e. link is not complete until linked record

completes processing

block - boolean, i.e. dont do any more record processing until link

completes

Could be implemented easily as follows:

When link support returns it specifies 1) If wait is true, i.e. it

will call a callback when the link completes and

2) If block is true. If wait is true Record support incremements a

counter indicating how many callbacks are outstanding. If block is

true, record support will not do any more record processing until all

outstanding callbacks complete.

This is simple and efficient. Is it intuitive for the Application

Developer?

With regards to the example of the array of processLink, I say yes.

The application developer has control of the order. If the definition

is:

processLink = [3] {
       {pvname = "incA"; wait=true},
       {pvname = "incB"; wait=true,block=true},
       {pvname = "getSample"; wait=true;}
}

The link for getSample will not be requested until both incA and incB

complete. I think this is intuitive.

There is a problem for separate link fields rather than an array of

links.

Now the order in which the fields appear in the record matter. The

order can never be changed or databases will break.

I still hold up my already expressed concerns:

    * The configuration has different lines  for "incA" and "incB",
      while in the course of record execution they are treated the same.

??? Since this is an array of links the semantics are do link[0] then

link[1], ... Thus the order is clear.

    * The "block" statement in your example controls something that
      happens afterwards, it would logically apply to "incA" in the
      same fashion.
      It is really rather the "getSample" link whose execution is
      blocked until all previous records have finished.
      I see a good chance of confusion as the designer always has to
      remember: Does "block=true" mean that this record is blocked or
      that the next record is blocked?

If I understand you are saying that block should mean
"Dont start processing THIS link until all previous links have completed"

This does seem to make sense and can be implemented just a efficiently

as the original proposal.

Thus we can define

block - wait until all previous record processing activity has completed
process - request the linked record be processed

wait - do not complete this link until the linked record has completed

processing.

    * What happens if I set a link "wait=false, block=true"?

    * Why doesn't the "getSample" have a "block=true" definition?
      Isn't further processing of the record held up until the
      processing is finished? Is "block=true" inherent for the last
      link in the array? Even if it is set "wait=false"?

I think redefining block as above makes these problems go away.

   *

I guess what you really want to do is define a /group/ of records that

are waited for. The "block" directive is just a way of getting around

a real group definition syntax. With side effects.

In a different view: It looks like your "block=true" really defines

something like a /checkpoint/ ("proceed after all outstanding procs

have finished") after the link it is attached to. Is there a way to

declare such checkpoints within the array, but separate from the links?

Seems like the "block" directive introduces some dangerous mixture of

data (link info) and control (group info, checkpoints). Should these

things be rather separated?

Perhaps dangerous but powerfull. The Application developer is in charge.

The support developer (record, link, struct) just has to make sure the

order of link, struct fields is never changed if changes are made to a

dbd file. The defaults should be so that if fields are added existing

record instances do not break.

Marty

Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System