[Fwd: Re: Link arrays / syntax]

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

--- Begin Message ---

Subject:	Re: Link arrays / syntax
From:	Ralph Lange <Ralph.Lange@bessy.de>
To:	Marty Kraimer <mrk@aps.anl.gov>
Cc:	Andrew Johnson <anj@aps.anl.gov>
Date:	Wed, 28 Sep 2005 16:19:35 +0200

Marty Kraimer wrote:

http://www.aps.anl.gov/epics/wiki/index.php/V4_DB_RecordCommon
defines MonitorLink, InputLink, OutputLink, ProcessLink.

Lets just look at ProcessLink since InputLink and OutputLink are similar since they all have a field parallel

struct(ProcessLink) {
field(pvname,string) { link}
field(parallel,bool)
field(wait,bool)
}


Perhaps this should be changed to

menu(LinkWait) {
choice(linkWaitNo,"no")
choice(linkWaitYes,"yes")
choice(linkWaitBlock,"block")
}

struct(ProcessLink) {
field(pvname,string) { link}
field(wait,menu(LinkWait))
field(timeout,double64)
}

Then

void collectSample=processLink=[3] {
{pvname="incA”; wait=yes,timeout=2.5},
{pvname="incB”; wait=block,timeout=2.5},
{pvname="getSample”; wait=block,timeout=5.0}
}
}

Thoughts?

Hm.... two issues:

1.
I still don't like that incA and incB are defined differently, while in terms of processing they really are treated the same, i.e. symmetrical. What I mean: In your suggestion the "wait=block" in incA is still blocking the next record, not the record that it is defined for.
Also the word "block" itself is ambiguous: "block" processing a record until something occurs or configure this link to be part of a "block" of links that are waited for as a group.

2.
I did not mean the time value to work as a timeout, but really as a wait interval that is added after processing is found as complete or after requesting the processing (if wait=no).
In general, a timeout seems to be a valuable feature so that things are not held up indefinitely. BUT: With a timeout one would probably like to be able to decide how processing the other links will continue after a timeout occurs. Might need additional thought - wait time seems to be easier to implement.

So ... ... ... what about:

menu(LinkWait) {
choice(linkWaitNo,"no")
choice(linkWaitYes,"yes")
choice(linkWaitGroup,"group")
}

struct(ProcessLink) {
field(pvname,string) { link}
field(wait,menu(LinkWait))
field(delay,double64)
}

so that the example is:

void collectSample=processLink=[3] {
{pvname="incA”; wait=group},
{pvname="incB”; wait=group,delay=1.0},
{pvname="getSample”; wait=yes,delay=5.0}
}
}

where the "wait" option always defines how waiting for this record is to be handled and the "delay" time is added before this record is being processed. All contiguous "wait=group" records are processed according to their individual delays, then waited for as a group. So for my example the process order would be:
- start processing incA
- wait for 1 second
- start processing incB
- wait for incA and incB to finish processing
- wait for 5 seconds
- start processing getSample
- wait for getSample to finish processing

As for timeout ....

An easy implementation of timeout would be:
- "Timeout" is the time span after which this record's processing is regarded as finished no matter of its actual state.
That definition does not include recognition of timeouts, but would allow to keep things from blocking completely. I'm not sure, though, if simply continuing without being able to add timeout handling would be a real improvement.

What do you think?

Ralph

--- End Message ---

--- Begin Message ---

Subject:	Re: Link arrays / syntax
From:	Ralph Lange <Ralph.Lange@bessy.de>
To:	Marty Kraimer <mrk@aps.anl.gov>
Cc:	Andrew Johnson <anj@aps.anl.gov>
Date:	Wed, 28 Sep 2005 17:15:31 +0200

Did you have a look at my mail?

Most of my concerns are probably still valid.

Sorry to be out-of-sync on this one ...

Ralph


Marty Kraimer wrote:

I am really sorry. I made som major changes to the talk yesterday and forgot to send a message to core-talk.

I will send it after Im answer this message.

The example now reads:

void collectSample={
processLink=[3] {
{pvname = “incA”; wait=true; block=false},
{pvname= “incB”; wait=true; block = true},
{pvname= “getSample”; wait=true; block=true}
}
}

I will agree that the names wait and block may not be correct. But what to use?

Every word I think of is already overloaded. Note that the meaning is

wait - really means: When the link completes call a record support supplied callback. The record will not be allowed to complete processing until all outstanding callbacks have been called.

block - really means: Dont do any more processing of the record until all outstanding wait callbacks have been called.

I am open to suggestion for good names.

Forget timout for a second. I am making changes that will allow the timeout to be specified when a record instance is created. It will appear in the dataStruct related to the record.

Marty.

P.S. A message to core-talk coming soon. Again sorry I did not send it yesterday.

--- End Message ---

--- Begin Message ---

Subject:	Re: Link arrays / syntax
From:	Ralph Lange <Ralph.Lange@bessy.de>
To:	Marty Kraimer <mrk@aps.anl.gov>
Cc:	Andrew Johnson <anj@aps.anl.gov>
Date:	Wed, 28 Sep 2005 17:56:36 +0200

Marty Kraimer wrote:

Ralph Lange wrote:

So ... ... ... what about:

menu(LinkWait) {
choice(linkWaitNo,"no")
choice(linkWaitYes,"yes")
choice(linkWaitGroup,"group")
}

struct(ProcessLink) {
field(pvname,string) { link}
field(wait,menu(LinkWait))
field(delay,double64)
}

so that the example is:

void collectSample=processLink=[3] {
{pvname="incA”; wait=group},
{pvname="incB”; wait=group,delay=1.0},
{pvname="getSample”; wait=yes,delay=5.0}
}
}

Is this really better than wait and block?

Don't get me wrong - it actually does mean wait and block. I just changed the syntax to be more comprehensive:

Your example is functionally equivalent to my example

incA wait=yes incA wait=group
incB wait=block incB wait=group
getSample wait=block getSample wait=yes

but in your case the syntax is assymetrical, so you can't e.g. swap the incA and incB links. (It would change the grouping of links.) For my suggestion links that are treated the same also are configured the same. It is more obvious that incA and incB belong to a group of links that are waited for in parallel.

Again why have delay as part of every link. Note that with the new style links they should be waiting until some physical "thing" is done. Specifying a delay says "I think maybe this will be enough time for X to complete". Let the experimenter create a set of records that dont complete until X really completes.

I was just thinking that extending the general functionality of links in such way would make the seq record obsolete. But if you don't like it - just ignore it. My main issue is a more comprehensive "grouping" of links I mentioned above.

Ralph

--- End Message ---

--- Begin Message ---

Subject:	Re: Link arrays / syntax (fixed alignment)
From:	Ralph Lange <Ralph.Lange@bessy.de>
To:	Marty Kraimer <mrk@aps.anl.gov>
Cc:	Andrew Johnson <anj@aps.anl.gov>
Date:	Wed, 28 Sep 2005 17:58:25 +0200

Marty Kraimer wrote:

Ralph Lange wrote:

So ... ... ... what about:

menu(LinkWait) {
choice(linkWaitNo,"no")
choice(linkWaitYes,"yes")
choice(linkWaitGroup,"group")
}

struct(ProcessLink) {
field(pvname,string) { link}
field(wait,menu(LinkWait))
field(delay,double64)
}

so that the example is:

void collectSample=processLink=[3] {
{pvname="incA”; wait=group},
{pvname="incB”; wait=group,delay=1.0},
{pvname="getSample”; wait=yes,delay=5.0}
}
}

Is this really better than wait and block?

Don't get me wrong - it actually does mean wait and block. I just
changed the syntax to be more comprehensive:

Your example                 is functionally equivalent to my example

incA wait=yes                incA wait=group
incB wait=block              incB wait=group
getSample wait=block         getSample wait=yes

but in your case the syntax is assymetrical, so you can't e.g. swap the
incA and incB links. (It would change the grouping of links.)
For my suggestion links that are treated the same also are configured
the same. It is more obvious that incA and incB belong to a group of
links that are waited for in parallel.

Again why have delay as part of every link. Note that with the new style links they should be waiting until some physical "thing" is done. Specifying a delay says "I think maybe this will be enough time for X to complete". Let the experimenter create a set of records that dont complete until X really completes.

I was just thinking that extending the general functionality of links in
such way would make the seq record obsolete. But if you don't like it -
just ignore it. My main issue is a more comprehensive "grouping" of
links I mentioned above.

Ralph

--- End Message ---