Experimental Physics and
Industrial Control System

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.