Re: Link arrays / syntax

[Marty Kraimer <mrk@aps.anl.gov>]

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