On 7/17/20 9:33 AM, Michael Davidsaver wrote:
> The python subprocess module shouldn't let this happen though since it does
> fork() and then execv(), and the situation which I describe is only possible
> if fork() is not followed by execv().
Oh wait. CAProcess (which I've not seen previously) is using
the multiprocessing module, which can do fork() without exec().
In fact, this is the default on *NIX. So this is likely or
problem. I think you'll need to use the 'spawn' or 'forkserver'
method.
Well, CAProcess deletes the CA context and clears any cached CA data before the forked process runs so that the process will create and use its own CA context.
The problem actually reported happens when trying to create 25,000 unused CAProcesses, none of which did any real CA work.
But, sure, creating many CAProcesses from a CAThread to do work that might want to connect (each with their own CA context) to PVs might not be the wisest approach. One could have separate worker processes running, ready to react to messages (perhaps from CA) to start some long-running work.
What I find most confusing is the fact that the program creates a CAThread from pycaspy write(). Some value in a python program changed and you want to send that to the outside world via CA (and are using pycaspy because you were too lazy to create a PV in a softIoc or this is all too dynamic to capture in a softIoc?) *and* you want to notify another thread in the same program that the value changed, and you decide that CA is the right way to send that message. For communicating within a single process, you don't need CA at all.
--Matt
