On Sat, May 4, 2019 at 1:35 PM Michael Davidsaver via Tech-talk <
[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.
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.
> 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. 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.
