Hi!
I have a custom class that inherits from asynPortDriver, but it also overrides the readUInt32Digital, readInt32 and readFloat64 methods, such that they read values from hardware to provide up to date information. Most of our records for this IOC use SCAN set to I/O Intr, and we update values read from hardware when processing writes into hardware. However, we have some records for which we needed to use periodical SCAN ('0.1 second', in this case), due to their monitoring purpose, and they use the aforementioned read* methods to obtain values from hardware.
Unfortunately, when the IOC is exited (with 'exit' in the IOC shell, for example), it seems our asynPortDriver is destroyed before the thread responsible for the record updates is. This leads to multiple use-after-free issues during IOC exit; they can be seen with pthread_mutex_* functions returning EINVAL, and sometimes triggering assertions in our backend.
What is the recommended way forward here? Having things misbehave during exit is not the worst that could happen, but it's still an issue. The alternative I can see is adding a thread that polls through these HW values and using I/O Intr for the records. I think this would always work, but it feels ugly, given that Epics already has periodical SCAN functionality.
Thank you,
Érico
Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.
Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.
- Replies:
- RE: How to safely implement an asynPortDriver with SCAN records Mark Rivers via Tech-talk
- Navigate by Date:
- Prev:
Unexpected behavior when setting waveform PVs Érico Nogueira Rolim via Tech-talk
- Next:
PHP_EPICS module Remi Faure via Tech-talk
- 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: Unexpected behavior when setting waveform PVs Andrew Johnson via Tech-talk
- Next:
RE: How to safely implement an asynPortDriver with SCAN records Mark Rivers via Tech-talk
- 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
|