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.
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().
Could 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
--
The best FOSS code is written to be read by other humans -- Harold Welte
- Replies:
- Re: some field definitions Marty Kraimer
- References:
- Re: some field definitions Andrew Johnson
- Re: some field definitions Marty Kraimer
- Navigate by Date:
- Prev:
Re: some field definitions Tim Mooney
- Next:
Re: some field definitions Marty Kraimer
- 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 Marty Kraimer
- Next:
Re: some field definitions Marty Kraimer
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|