EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Concerns about link-support-2 branch
From: Michael Davidsaver <[email protected]>
To: "Johnson, Andrew N." <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Tue, 7 Mar 2017 09:57:58 -0500
On 03/07/2017 01:08 AM, Johnson, Andrew N. wrote:
> Hi Michael,
> 
> Please take another look, my changes have not modified the dbGetAlarm() or dbGetTimestamp() APIs at all, they still call straight through into the appropriate plset->getAlarm() and plset->getTimestamp() methods of the underlying link-type. Both the code samples you showed should still work without any changes.

Maybe I was rambling too much.  Let me be clear.  I see no regression in
this change.

> 
> The change I made in that commit was to the plset->getValue() method, which is called by the dbGetLink() API. Previously dbGetValue() would call recGblInheritSevr() itself after calling the plset->getValue() method as long as the return status wasn't an error; the only difference is that now the link type must make that call itself as part of the functionality of its getValue method. This does not change the functionality of the existing higher level API routines at all.

I don't like the existing behavior of the dbGet*() calls.  I've realized
that the code I've been writing is open to race conditions w/ CA_LINK.
I want to see this "fixed".  I agree that fixing dbCa.c is out of scope
for your branch.  However, I think that such a fix will be complicated
by introducing another layer of public API.

> If you want to change the semantics of the API routines we can discuss any proposal you want to bring up, but the current link-support-2 branch changes don't currently make any that I know of.

I know I've been beating you up on this for months, so I won't insist of
a redesign now.  However, I don't want to set this API in stone  until a
discussion has taken place.  So I would be willing to move forward with
the qualification that the link support API be considered provisional in
3.16 (or feature preview, or whatever term you like).


Replies:
Re: Concerns about link-support-2 branch Andrew Johnson
References:
Concerns about link-support-2 branch Andrew Johnson
Re: Concerns about link-support-2 branch Michael Davidsaver
Re: Concerns about link-support-2 branch Johnson, Andrew N.

Navigate by Date:
Prev: Re: Concerns about link-support-2 branch Johnson, Andrew N.
Next: Jenkins build is still unstable: epics-base-3.14-win64s #184 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Concerns about link-support-2 branch Johnson, Andrew N.
Next: Re: Concerns about link-support-2 branch Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·