EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  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  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: dbGetPdbAddrFromLink dropped from 3.15 again
From: "Johnson, Andrew N." <[email protected]>
To: Michael Davidsaver <[email protected]>
Cc: EPICS Techtalk <[email protected]>
Date: Sat, 4 Aug 2018 15:43:25 +0000
My assumption is that they’re wanting direct access to a large block of data without copying it. This should safe for DB links because of the IOC locking, as long as they aren’t copying pointers out of the dbAddr or using it outside of the locked record that is requesting it, so I could see us adding another API to the LSET that allows that for link types that can provide it.

I would be wary of just handing out the dbAddr* pointer though, since the link could get changed without any notice, so I would like to add a little more enforcement. Some link types could even use this to provide access to their raw data buffers, so I’m wondering about an API like doLocked() where the caller gives us a function pointer which we call back with a dbAddr*.

Till, would something like that work for your situation?

- Andrew

-- 
Sent from my iPad

> On Aug 2, 2018, at 11:02 PM, Michael Davidsaver <[email protected]> wrote:
> 
>> On 07/31/2018 01:16 PM, Till Straumann wrote:
>> I'm running into the same issue that was discussed here:
>> 
>> https://epics.anl.gov/tech-talk/2017/msg01247.php
>> 
>> Michael's answer (https://epics.anl.gov/tech-talk/2017/msg01268.php)
>> recommends replacing subRecord by aSubRecord -- however, my use case
>> rather fits the first scenario mentioned by Michael: avoiding the overhead of dbGet()
>> 
>> What is the recommended migration path for this case?
> 
> Can you give some more details?  How do you use the dbAddr* which was being returned?
> 
> 
>> I guess I could use
>> 
>>    dbGetNelements(const struct link*)
>>    dbGetLinkDBFtype(const struct link*)
>> 
>> to make sure the target of my link matches the expectations -- but there is
>> no way to access the data the link points to without either making a copy
>> (dbGet) or exploiting internals (which is deprecated/discouraged)
>> 
>> :-(
>> 
>> Like other posters I'm looking for a minimally intrusive (and yet 'safe') solution
>> for a legacy system with not much horse-power.
>> 
>> - Till
> 

Replies:
Re: dbGetPdbAddrFromLink dropped from 3.15 again Michael Davidsaver
References:
dbGetPdbAddrFromLink dropped from 3.15 again Till Straumann
Re: dbGetPdbAddrFromLink dropped from 3.15 again Michael Davidsaver

Navigate by Date:
Prev: Re: DBE_PROPERTY and Gateway Shankar, Murali
Next: Re: streamDevice 32-Bit ULONG endianess Dirk Zimoch
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  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: dbGetPdbAddrFromLink dropped from 3.15 again Michael Davidsaver
Next: Re: dbGetPdbAddrFromLink dropped from 3.15 again Michael Davidsaver
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  <20182019  2020  2021  2022  2023  2024 
ANJ, 06 Aug 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·