| 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: [Merge] ~dirk.zimoch/epics-base:FilterForInfoFields into epics-base:7.0 |
| From: | mdavidsaver via Core-talk <core-talk at aps.anl.gov> |
| To: | mp+399414 at code.launchpad.net |
| Date: | Wed, 10 Mar 2021 20:23:39 -0000 |
> What happens when the record owns a reference and we lock it and then access the data can be called "borrowing". This is a temporary state and not a property of the db_field_log. By "borrowed" I was meaning that a db_field_log which references a buffer which may only be accessed with a dbScanLock() of the associated record. Indeed struct db_field_log does not current encode this associate fully. I think that you and I (Ben) probably have the same idea with only a sign flip in the name. Would you agree that "is_owner==!must_lock"? In your mind, does "is_owner" have a wider meaning than record locking? eg. does "is_owner" imply anything about the presence or absence of a dtor? -- https://code.launchpad.net/~dirk.zimoch/epics-base/+git/epics-base/+merge/399414 Your team EPICS Core Developers is requested to review the proposed merge of ~dirk.zimoch/epics-base:FilterForInfoFields into epics-base:7.0.