EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20192020  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  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: libca bug?
From: Michael Davidsaver via Tech-talk <[email protected]>
To: Matt Newville <[email protected]>
Cc: tech-talk <[email protected]>
Date: Mon, 6 May 2019 10:30:20 -0700
On 5/5/19 9:04 AM, Matt Newville wrote:
> (conversation seems to have jumped threads... not sure why)

Attempting to jump back...

> On Sat, May 4, 2019 at 1:35 PM Michael Davidsaver via Tech-talk <[email protected] <mailto:[email protected]>> wrote:
> 
>     On 5/4/19 8:29 AM, Matt Newville wrote:>
>     ...
>     > OK, thanks -- that might be useful. To be clear, this returns False for me in the "normal" case of actually loading `libca` for the first time from a Python session:
> 
>     This depends on how LoadLibrary() is calling dlopen().  cf. RTLD_LOCAL vs. RTLD_GLOBAL.
>     The default is RTLD_LOCAL.  fyi. this is actually controllable with
>     sys.setdlopenflags(), though I've not tried changing this myself.
> 
> 
> I think we want to avoid using RTLD_GLOBAL.   That's probably especially true when embedded in an application that is loading and using libca itself.   

I can see why the cpython dev.s default to RTLD_LOCAL, and the ctypes API makes changing this
unappealing.  Personally, I would want to avoid any situation where libca.so were loaded twice
into the same process.

>     Libraries loaded during normal process start behave as RTLD_GLOBAL.
> 
>     > $ softIocPy2.7
>     > epics> py "from ctypes import cdll"
>     > epics> py "print hasattr(cdll.LoadLibrary(None), 'ca_context_create')"
>     > True
> 
> 
> Yes, it appears to return True when the application has that shared lib loaded when the Python interpreter is created (or initialized -- don't know that it matters here but maybe, and maybe that depends on details of how pyDevSup works).  I think that is why it might be useful.    
> 
> FWIW, I don't think we want to use
>      getattr(cdll.LoadLibrary(None), 'ca_context_cache', None)   
> 
> as the normal way to look up the `ca_context_cache` function when `lbca.ca_context_create` will do.

This was only a way to shorten the example.

> 
>     > So that might be a reliable way to answer the question "am I running as an embedded Python within an IOC-like process that has loaded libca?".  That would be good to know.  Registering epicsAtExit() might be useful in all cases, but it seems like we might really need to do that when embedded in an IOC.
> 
>     Since libca is registering its own exit handler pyepics would want to
>     do the same (after ca context creation) to avoid racing against this
>     cleanup when epicsExit() is called.
> 
> 
> I am completely willing to believe we would need to do this (or something like it) in order to use pyepics embedded in an IOC.  Apparently it has not been needed when running as a normal Python process.

Yup.  I'm not sure of the details, but I think this is related to the way in which
IOCs exit, and what pyDevSup is forced to do as a result.  In a normal python
process (main() from Modules/main.c), Py_Finalize() happens before exit().
So all python atexit hooks have run, and all non-daemon Threads have stopped,
before any epicsAtExit() hooks.

With pyDevSup, I have to use an epicsAtExit() hook call to Py_Finalize().
But mine may not be the first hook to run.  I think cacExitHandler() is
being run before cleanupPy().

>  There might be no harm in always registering an exit handler, but it might require some code changes and testing to do so.  We don't want the "normal" non-embedded case worse.   That's why a test of "was libca loaded by an enclosing process" might be useful.
> 
> I've not yet used pyDevSup myelf, but trying to make pyepics work in a python process embedded in an IOC sounds like a fine idea to me.  Currently, pyepics is not testing that. I could be wrong, but it looks to me like pyDevSup isn't testing the use of pyepics.  Without such tests, I don't think it is really sensible to expect this combination to work without some real effort.

Yup.  Coordinating clean shutdown of a multi-threaded app. isn't a "just works" situation.
Adding multiple exit hook mechanisms to the mix doesn't help this.

Replies:
Re: libca bug? Matt Newville via Tech-talk
References:
libca bug? Bruno Martins via Tech-talk
Re: libca bug? Matt Newville via Tech-talk
Re: libca bug? Michael Davidsaver via Tech-talk
Re: libca bug? Matt Newville via Tech-talk

Navigate by Date:
Prev: Re: libca bug? Johnson, Andrew N. via Tech-talk
Next: Re: libca bug? Michael Davidsaver 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  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: libca bug? Michael Davidsaver via Tech-talk
Next: Re: libca bug? Matt Newville 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  <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 ·