Hi Ralph,
On Thursday 10 December 2009 10:28:39 Ralph Lange wrote:
>
> Real world example:
Sorry, I do understand the desire to be able to do a put without processing,
my skepticism was with the possibility of actually doing it, because we'd need
to do a "put without proc" on initial connection but a "put with proc" on
later record processing. That needs changes to the CA protocol to add the
proc flag as you realize; we couldn't even do it using a {process:true} field
modifier since that's a different channel.
> On the other hand, as the workaround is simple and reliable (put C in
> auto-save/restore pass 1), I'm not sure how much effort can be justified.
Right, not worth bothering with.
> Hm... I would really like the link spec being able to specify processing
> the target on OUT links, too (instead of using the target field's PP
> flag), so that the CA related flag set would become:
>
> CA Force link to use CA
> CP Force CA, process receiving record (both INP and OUT links)
> CPP Same, but only if receiving record is passive (INP and OUT)
> SOR Send on reconnect
> POR Process on reconnect (only passive if CPP is true)
We can implement the choice of whether to process the target or not after a
put by using a field modifier. The default should still be determined by the
field's PP setting, but could be overridden by appending {process:true} or
{process:false} to the field name. However CAv3 doesn't have the ability to
tell the target whether to process or not after a put, so your SOR/POR
distinction is not currently possible.
I would also add that if an OUT link has never been activated it doesn't know
what data to send (or even what data type to use), which is why I much prefer
ROR = Resend-On-Reconnect, it describes the actual behavior of the current
code better.
> Actually, things could then even be made more orthogonal:
>
> <none>/CA Auto link [default]
> / Force CA link
> <none>/P/PP No processing [default]
> / Process receiver
> / Process receiver if Passive
> <none>/SOR/POR/PPR No reconnect action [default]
> / Only send on reconnect
> / Send and process receiver on reconnect
> / Send and process rec. on reconnect if Passive
>
> For completeness, DB could be added for the first set to force local
> resolution (I don't see a use case, though).
I could see some applications using a DB flag, presumably it would generate a
warning or error message at iocInit time when the links get resolved and would
prevent the link from being presented to CA for resolution. It isn't really
necessary though, it just provides a hint to a later developer that there's
some reason that these two records must be located in the same IOC.
> The second set would be valid for DB and CA links.
> The third set would be valid for CA links only.
> All sets would be valid for INP and OUT links.
Still needs CAv3 to be able to send a Process bit with puts, with all the
backwards compatibility issues that raises. My field modifier idea above
doesn't suffer from that.
> To keep compatibility, on input links .CP would translate to .CA.P and
> .CPP to .CA.PP (sorry to be obvious).
FYI the way the link flag parser currently works we can't have single letter
options unless that letter doesn't appear in any other flags. Basically if
one flag name is a substring of another the two must be strictly exclusive; we
always search for the longest first since this parsing is currently done using
strstr() on the part of the link string following the PV name.
I want to replace the existing link syntax with a JSON-encoded object instead,
which will give us much more flexibility and better parsing, thus I don't
recommend spending too much time thinking about or enhancing the existing link
syntax.
- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte
- References:
- Re: CA link behavior Andrew Johnson
- Re: Fwd: CA link behavior Andrew Johnson
- Re: Fwd: CA link behavior Ralph Lange
- Navigate by Date:
- Prev:
OMS MAXv driver Mark Rivers
- Next:
EPICS database comparison Pam Gurd
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Fwd: CA link behavior Ralph Lange
- Next:
aSub and C++ Simon Hoyle
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|