Experimental Physics and Industrial Control System
Hi Tim, etc.
Thanks for all your detailed and wonderful explanations. More
questions related to waveform record:
The dynamic array sizing was introduced in 3.14.12. When I diff the
waveformRecord.c (.dbd) between 3.14.11 and 3.14.12, I don't see any
fundamental changes contributing to dynamic array sizing. Questions:
1. Which source files in the base were changed/improved to make
dynamic array sizing work? How can I locate those changes through the
launchpad repository?
2. I tested this new feature under 3.14.12 IOC paired with 3.14.12
camonitor. I used the classic exampleApp and added one waveform record
which has NELM greater than 10 and reads data from the compress
record. As you know, the compress record is a circular buffer with
data range from 0 to 9. When I camonitor the waveform record, I get
array data like [0], [0 1], [0 1 2], ..., [0 1 2 ... 9], [1 2 3 ... 9
0], [2 3 4 ... 9 0 1] ... For the array data [2 3 4 ... 9 0 1], how
"dynamic array sizing" knows the '0' is real data, not zero-filling
ending? i.e. why can I get [2 3 4 ... 9 0 1] rather than [2 3 4 ...
9]?
I do make a search on tech-talk archive before I post a question. But
the search usually gives lots of threads or nothing. I hope it's OK
here to ask any kind of questions, either naive or complicated, either
new or repeated.
Thanks,
Jack
On Fri, Oct 26, 2012 at 12:06 PM, Tim Mooney <[email protected]> wrote:
> There have been several good answers, but I think there is still a little uncovered territory:
>
> ----- Original Message -----
>> From: "Jack Smith" <[email protected]>
>> To: [email protected]
>> Sent: Thursday, October 25, 2012 10:31:22 PM
>> Subject: waveform record: how its VAL get data? any potential memory leak? ...
>> Hello everyone,
>>
>> I'm looking through the source code of the waveform record and trying
>> to understand how the it works. A few questions:
>>
>> 1. How does the BPTR field transfer data to VAL? Why do we have to set
>> NORD in the device support?
>
> BPTR is a pointer to the array, and the record-support routine cvt_dbaddr() converts a
> client's reference to VAL to a reference to BPTR. When the array is posted, it is
> BPTR, not VAL, that is posted.
>
> Device support has to set NORD because only device support knows how many elements it read.
>
>> 2. During the record initialization, there is memory allocation by
>> callocMustSucceed( ). I remember some programming experts claim that
>> malloc (or new) must be paired with free (or delete) in a program to
>> prevent memory leak. If that is true, how should we deal with this
>> allocated memory in the lower level such as device support or driver
>> support to prevent memory leak? If I type "exit" to kill a Linux IOC,
>> will the memory allocated to the waveform record be released
>> automatically so that there is actually no memory leak problem?
>>
>> 3. When I look at waveformRecord.dbd, the field type of both VAL and
>> BPTR is DBF_NOACCES which I guess means no access to this field from
>> the database outside. It's true that I can't camonitor
>> waveform-record.BPTR, but obviously we can camonitor
>> waveform-record(.VAL). So, why does the DBF_NOACCES affect the VAL
>> field and the BPTR differently? What kind of magic makes VAL
>> accessible while BPTR inaccessble?
>
> It's not essential that the record have two fields associated with the data array.
> In the waveform record, VAL functions only as a redirect to BPTR, but it could also
> have held the array pointer. Other records that have arrays use only one field. It
> doesn't matter as long as the field definitions and the cvt_dbaddr() routine are
> consistent with each other.
>
> The VAL and BPTR fields are DBF_NOACCESS for several reasons: because cvt_dbaddr() will
> take over the job of specifying the field type at run time; because the field won't be
> functional until init_record() has allocated memory for it; and because the value of BPTR
> is not the data by the address of the data. waveformRecord.dbd indicates that cvt_dbaddr()
> will be used to override the field type (and otherwise manage access to the field) by
> specifying "special(SPC_DBADDR)".
>
>> Thanks,
>>
>> J.S.
>
> --
> Tim Mooney ([email protected]) (630)252-5417
> Software Services Group (www.aps.anl.gov)
> Advanced Photon Source, Argonne National Lab
- Replies:
- Re: waveform record: how its VAL get data? any potential memory leak? ... Andrew Johnson
- References:
- waveform record: how its VAL get data? any potential memory leak? ... Jack Smith
- Re: waveform record: how its VAL get data? any potential memory leak? ... Tim Mooney
- Navigate by Date:
- Prev:
User Created File Types: FILE TYPE += ABC [EPICS R3-14-12] Ernest L. Williams Jr.
- Next:
3.14 v.s. 3.15 vs. v4 Jack Smith
- 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: waveform record: how its VAL get data? any potential memory leak? ... Tim Mooney
- Next:
Re: waveform record: how its VAL get data? any potential memory leak? ... Andrew Johnson
- 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