EPICS Re: RPRO inconsistency

Experimental Physics and Industrial Control System

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: RPRO inconsistency
From:	Michael Davidsaver <[email protected]>
To:	"Johnson, Andrew N." <[email protected]>
Cc:	EPICS core-talk <[email protected]>
Date:	Mon, 22 Jan 2018 21:34:07 -0800

On 01/22/2018 06:12 PM, Johnson, Andrew N. wrote:
> Hi Michael,
> 
> I think you are right about the subtlety of this issue, I seem to remember wanting to make that change many years ago but was persuaded (or I discovered) it would be a bad idea. I think it relates to preventing infinite loops using DB links — if you make that change I suspect a record that FLNKs to itself will eat up 100% of a UP CPU.

yup...  this isn't as simple as I had hoped.  Still, I'd like to explore if this can be fixed.
So down the rabbit hole I go...

https://code.launchpad.net/~epics-core/epics-base/+git/prop-putf/+merge/336468

An attempt to fix this for the specific use case I care about.  When
a scan chain containing async records is originally triggered by
remote user action via. dbPutField().

References:: RPRO inconsistency Michael Davidsaver; Re: RPRO inconsistency Johnson, Andrew N.

Navigate by Date:: Prev: Re: RPRO inconsistency Johnson, Andrew N.; Next: Problems with parallel make in base 7.0.1.1 on Visual Studio 2015 and Visual Studio 2017 when HOST_OP=NO Mark Rivers; 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: RPRO inconsistency Johnson, Andrew N.; Next: areaDetector developers meeting @ APS Mark Rivers; Index: 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024