EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: [Merge] ~info-martin-konrad/epics-base:dont-nuke-global-cac-thread-id-in-exit-handler into epics-base:3.15
From: Andrew Johnson via Core-talk <[email protected]>
To: [email protected]
Date: Mon, 06 May 2019 20:25:36 -0000
Review: Needs Fixing

RTEMS and VxWorks both use the same basic implementation of epicsThreadPrivate variables for which the delete function does nothing:

> void epicsThreadPrivateDelete (epicsThreadPrivateId id)
> {
>     /* empty */
> }

I thought that we used this code everywhere, (I'd forgotten that we even provided a Delete() function for the API) but I was obviously wrong; both the Posix and Windows implementations /are/ different and rely on the OS to allocate IDs. On Posix reusing a pthread_key_t value after deleting it results in undefined behavior, but I suspect that in practice the storage in any other threads doesn't get deleted immediately, which is why Bruno's test worked.

The rationale section in the Linux pthread_key_delete() man-page describes how fraught with difficulty deleting the ID/key of a thread-private variable is in practice, and in Base most code doesn't delete the ID at all. Both the 3.15 and 7.0 branches contain 10 calls to epicsThreadPrivateCreate() and only 2 calls to epicsThreadPrivateDelete(), one of which is in the destructor for the C++ epicsThreadPrivate<T> template class (which only seems to be used in test programs), the other is here in CA's cacExitHandler().

I agree with Michael that removing the cacExitHandler() is probably the best solution. My previous commit already added a Release Note, the wording of which still applies, so it would make sense to modify this merge to finish off the necessary changes.
-- 
https://code.launchpad.net/~info-martin-konrad/epics-base/+git/epics-base/+merge/366996
Your team EPICS Core Developers is subscribed to branch epics-base:3.15.

References:
[Merge] ~info-martin-konrad/epics-base:dont-nuke-global-cac-thread-id-in-exit-handler into epics-base:3.15 Martin Konrad via Core-talk

Navigate by Date:
Prev: Build failed in Jenkins: epics-base-7.0-win64s-test #30 APS Jenkins via Core-talk
Next: Jenkins build is back to normal : epics-base-7.0-win64s-test #31 APS Jenkins via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: [Merge] ~info-martin-konrad/epics-base:dont-nuke-global-cac-thread-id-in-exit-handler into epics-base:3.15 mdavidsaver via Core-talk
Next: Re: [Merge] ~info-martin-konrad/epics-base:dont-nuke-global-cac-thread-id-in-exit-handler into epics-base:3.15 Martin Konrad via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
ANJ, 06 May 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·