| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Using DPVT for non-device support purposes |
| From: | Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "Wang, Andrew" <wang126 at llnl.gov>, EPICS tech-talk <tech-talk at aps.anl.gov> |
| Date: | Fri, 25 Nov 2022 13:14:15 -0600 |
|
Hi Andrew, On 11/25/22 12:34 PM, Wang, Andrew via
Tech-talk wrote:
I was wondering about the use of the dpvt pointer in a subroutine that the aSub record uses when it is processed. My understanding is that the dpvt pointer is used for device support, but I was wondering if it can also be used as an alternative to static variablesYes, the subroutine record types don't have any device support associated with them, so your subroutines are welcome to use that pointer for themselves if they wish. Record subroutines have to be re-entrant if they are used by more than one record instance, so static variables are not as useful in them as shown by your example — you would need to protect any accesses to static variables with an epicsMutex if you did want to use them as such since two subroutines could get processed by different threads at the same time, leading to a potential race condition. An additional related question: Suppose for device support, dpvt pointer points to a struct, which has a special free function associated with it (the struct might contain member variables that are dynamically allocated). Where can that be called so that there is no memory leaks from the IOC? The aSub record type has a function-pointer field prec->cadr which your subroutine can point to a cleanup function. It will be called (and passed prec) and then prec->cadr set to NULL whenever the SNAM field of the record gets changed. Note that the cadr won't be called when the IOC shuts down, for that you would need to register an epicsAtExit() routine to be called when the process exits. However if it's just freeing memory that you're worried about the IOC process exiting will normally return all of the process RAM back to the OS automatically; I would only worry about that when embedding the IOC into and running it within the context of another process. HTH, - Andrew -- Complexity comes for free, Simplicity you have to work for. |