2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Strange change in behavior from 7.0.1 to 7.0.2 |
From: | "Johnson, Andrew N. via Core-talk" <[email protected]> |
To: | "Rivers, Mark L." <[email protected]>, "[email protected]" <[email protected]> |
Date: | Thu, 24 Jan 2019 17:56:50 +0000 |
On 1/23/19 5:50 PM, Mark Rivers via Core-talk wrote:
So that will trigger some kind of RPRO behaviour. I wouldn't have called this a serious logic error at first glance, because in the original design _lim gets processed by a recursive call from the ao::process() routine while triggering its OUT PP link through _rel.FLNK. Since the _pos record is still active at that point (_pos.PACT is TRUE) the PP flags on the _lim.OUTx links would be ignored, and are thus harmless. However if the _lim record ever gets processed by some other means (i.e. not by the _pos.OUT PP → _rel.FLNK → lim path) it will result in the _pos record being processed 3 times in succession and triggering the _rel record from its OUT link, which is obviously unnecessary and probably undesirable given the calculation that _rel is doing. So writing to _pos over CA temporarily sets the _pos.PUTF field, indicating that the processing going on was caused by a request from outside the IOC. This is old behaviour, PUTF is cleared unconditionally at the end of recGblFwdLink() when the procesing has completed. What's new in 7.0.2 is that the OUT PP and FLNK links now cause that PUTF state to be propagated to the _rel and _lim records as well. Now when the _lim.INP links are read with PP causing them to attempt to process _pos again, they set _pos.RPRO. When the processing chain completes and recGblFwdLink() gets called for the _pos record, it will put the record onto the scanOnce queue resulting in the second processing that you're seeing. I can simplify your database to this using base-only record types: Which generates this output from 7.0.2:record(ao,"_pos") { field(OUT,"_rel.A PP") field(TPRO, 1) } record(calc,"_rel") { field(FLNK,"_lim") } record(calc,"_lim") { field(INPA,"_pos PP") field(INPB,"_pos.DRVL PP") field(INPC,"_pos.DRVH PP") } but this from 3.15:ca:anj@tux: dbProcess of '_pos' ca:anj@tux: dbProcess of '_rel' ca:anj@tux: dbProcess of '_lim' ca:anj@tux: dbProcess of Active '_pos' with RPRO=1 ca:anj@tux: dbProcess of Active '_pos' with RPRO=1 ca:anj@tux: dbProcess of Active '_pos' with RPRO=1 scanOnce: dbProcess of '_pos' scanOnce: dbProcess of '_rel' scanOnce: dbProcess of '_lim' scanOnce: dbProcess of Active '_pos' with RPRO=0 scanOnce: dbProcess of Active '_pos' with RPRO=0 scanOnce: dbProcess of Active '_pos' with RPRO=0 If there's a fix for this I suspect it belongs in dbDbLink.c's processTarget() routine. In the actions for the case 'else if (psrc->putf)' we know that pdst->pact is true so the destination record is busy, but maybe if pdst->putf is also true we should *not* set pdst->rpro, since it might be in our calling chain. Unfortunately pdst->putf might be true because it's in someone else's calling chain (in which case we probably *should* set pdst->rpro), but we currently have no way of distinguishing those two cases.ca:anj@tux: Process _pos ca:anj@tux: Process _rel ca:anj@tux: Process _lim ca:anj@tux: Active _pos ca:anj@tux: Active _pos ca:anj@tux: Active _pos I could see of a way around this by storing an identifier in the PUTF and RPRO fields which would let us see that (I'd make the PUTF and RPRO fields into DBF_LONG and use an atomic counter to generate a unique ID for each source put). Michael, what do you think? - Andrew -- Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." -- Edward Snowdon |