Hi Andrew.
Thanks for dealing with this issue.
I thought there were two problems to deal with:
1. internals/representation/semantics of DBADDR may change in the future
2. 'life-time' of the information in DBADDR
Regarding 2. I agree that a callback would be the best solution.
However, if you pass
a DBADDR* to that callback then its internals are obviously still
exposed and part of
the API. That's why I suggested passing a buffer pointer/#-elements/type
instead.
I would be fine with DBADDR*, too, of course.
Since 1. is (I hope) not going to happen in the 3.15 series there is no
need for a new API in 3.15
since I can simply 'redefine' the macro for my legacy application(s)
assuming that
- DBADDR won't change in 3.15 and is the same as in 3.14
- its contents do not change 'asynchronously' which I wouldn't assume
to happen under 3.15
in a legacy application (links don't change, no funny
double-buffering of arrays).
My application -- after obtaining the DBADDR* -- just de-references
it and computes stuff
from the buffer contents but doesn't call back into EPICS.
In a nutshell: for 3.15 my work-around is re-defining the legacy macro
and for future releases
I hope for a suitable API to appear :-)
Best regards
- Till
On 08/08/2018 09:26 AM, Johnson, Andrew N. wrote:
Hi Till,
I’m okay with stretching this conversation out, you’re the one who’s asking for a solution...
The dbAddr is designed to hold all the information you want and I don’t mind giving out a pointer to one as long as its lifetime is clear. A callback makes that obvious, whereas the original dbGetPdbAddrFromLink() obscures it.
Your suggestion to add a routine dbGetLinkBufPtr() suffers from the exact same problem, because while the other two dbGet... routines return information that is current at the time of the call, for another link type such as dbCa that could change immediately after they return. In 3.16 or 7.0 we already added another API with a callback which requires the link type to hold its internal mutex for the duration of the callback, so it can fetch data and metadata from the link atomically (e.g. value and timestamp).
Are you looking for this new API to appear in the 3.15 series? We can’t add a new LSET method here because we already added the other one in the later series, but I’d be okay with doing this as a special case for the earlier versions and adding the new LSET method in the later series to preserve backwards compatibility in out link types.
- Andrew
- References:
- dbGetPdbAddrFromLink dropped from 3.15 again Till Straumann
- Re: dbGetPdbAddrFromLink dropped from 3.15 again Michael Davidsaver
- Re: dbGetPdbAddrFromLink dropped from 3.15 again Johnson, Andrew N.
- Re: dbGetPdbAddrFromLink dropped from 3.15 again Michael Davidsaver
- Re: dbGetPdbAddrFromLink dropped from 3.15 again Andrew Johnson
- Re: dbGetPdbAddrFromLink dropped from 3.15 again Michael Davidsaver
- Re: dbGetPdbAddrFromLink dropped from 3.15 again Till Straumann
- Re: dbGetPdbAddrFromLink dropped from 3.15 again Johnson, Andrew N.
- Navigate by Date:
- Prev:
Re: Inverting control inputs on SIS3280? Mark Rivers
- Next:
Re: Inverting control inputs on SIS3280? Jesse Hopkins
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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: dbGetPdbAddrFromLink dropped from 3.15 again Johnson, Andrew N.
- Next:
Personal EPICS Building Environment Jeong Han Lee
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·