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? ... Jack Smith
- References:
- waveform record: how its VAL get data? any potential memory leak? ... Jack Smith
- Navigate by Date:
- Prev:
Re: waveform record: how its VAL get data? any potential memory leak? ... Michael Davidsaver
- Next:
probe 1.1.7.0 Xp_DIR patch J. Lewis Muir
- 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? ... Michael Davidsaver
- Next:
Re: waveform record: how its VAL get data? any potential memory leak? ... 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
|