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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows |
From: | "Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "Veseli, Sinisa" <sveseli at anl.gov> |
Cc: | "Nikitin, Viktor" <vnikitin at anl.gov>, "De Carlo, Francesco" <decarlo at anl.gov>, EPICS tech-talk <tech-talk at aps.anl.gov> |
Date: | Thu, 9 Sep 2021 22:06:02 +0000 |
On Sep 9, 2021, at 2:38 PM, Veseli, Sinisa via Tech-talk <tech-talk at aps.anl.gov> wrote:
There were also changes to the caProvider inside pvAccess made between Base 7.0.4.1 and 7.0.5 that made it more strict about saving and restoring the CA context pointer for the current thread, and changed the thread which is used to perform notifications
to the PVA client code. That could mean that calling pyepics code from inside a pvaccess callback/notification routine might no longer work if pyepics doesn’t properly set its CA context before calling routines inside libca (unfortunately that’s probably what’s
happening, given the access violation that Mark is seeing).
Calling pvaccess routines from inside a pyepics callback should be safe because now the provider routines first save the thread’s current context, set their own context, call libca, and then restore the previous context before returning. However notifications
from pvAccess may now be made by a thread that has no attached CA context, and if a libca routine gets called in that context it might trigger this kind of problem.
- Andrew
--
Complexity comes for free, simplicity you have to work for.
|