Tim,
Thanks for taking an interest in this thread. Your last message was
especially helpful.
Andrew Johnson wrote:
On Monday 27 April 2009 09:44:41 Marty Kraimer wrote:
Note that when the request was made to implement put notify I was
horrified about what this would take to implement. It is really a mess.
Note also that mrkSoftTest/iocBoot/iocput tests put notify.
I don't think this has anything to do with putNotify, it's simpler than that.
I dont understand this comment. The putApp test does test putNotify for
both synchronous and asynchronous records.
However after actually testing out my patch (thanks to Tim for prompting some
particular experiments) I realize that as written it just allows infinite
loops to be made without the need for even asynchronous processing.
I can see that setting RPRO in dbPutField() is essential to ensure that an
external put to a record that is waiting for the second half of asynchronous
processing will cause the record to be processed again to handle the new
field value. However I'm having trouble understanding why dbPutLinkValue()
ever needs to set RPRO.
Given this database:
record(ao,"$(user):lo1")
{
field(OUT,"$(user):lo2 PP")
field(TPRO,1)
}
record(ao,"$(user):lo2")
{
field(OUT,"$(user):lo1 PP")
field(TPRO,1)
}
the existing code does this when I do a caput to anjHost:lo1:
CAS-client: Process anjHost:lo1
CAS-client: Process anjHost:lo2
scanOnce: Process anjHost:lo1
scanOnce: Process anjHost:lo2
scanOnce: Active anjHost:lo1
It's rather hard to explain why both records should process twice, but they do
because of the PUTF sets RPRO test in dbPutLinkValue().
Tim's last message explains the problem. Let me repeat what he said.
Consider the following.
record(ao,"recB")
{
field(OUT,"recA PP")
field(TPRO,1)
}
record(ao,"recA")
{
field(OUT,"<hardware>")
field(TPRO,1)
}
a) putNotify to recA.VAL
b) recA.VAL converted to RVAL and asynchronous support starts
c) putNotify to recB.VAL
d) recB,VAL is written to recA.VAL
Unless RPRO is set true the VAL field of recA will be out of sync with
the RVAL that is written to hardware.
Marty
withCould it be something to do with preventing external interference in
processing inside the database? I guess if you had two records A (periodic)
which processes B (async), and the user pokes B directly, you'd want the
periodic scan to be able to reprocess B if the period arrives while B is
still busy.
This needs more thought, but that might explain why. Got to go now,
- Andrew
- References:
- Re: some field definitions Andrew Johnson
- Re: some field definitions Marty Kraimer
- Re: some field definitions Andrew Johnson
- Navigate by Date:
- Prev:
Re: some field definitions Andrew Johnson
- Next:
How to use process variable z abdou
- Index:
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: some field definitions Andrew Johnson
- Next:
How to use process variable z abdou
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|