zerorpc with gipc

[Han Chang]

I’m running into a weird problem with gipc and zerorpc - when I run a parent process that uses ZeroRPC clients, child processes created via gipc are not able to spin up their own ZeroRPC clients that connect to a ZeroRPC server.

I’ve created a simple repository that illustrates this issue:
https://github.com/hanchang/gipc_zerorpc_issue

Please first run `pipenv install` to install the dependencies in a local virtualenv (gipc and zerorpc).

The zerorpc_server.py file acts as a server that just prints its PID.
You can start it via `pipenv run python -m gevent.monkey zerorpc_server.py`

The gipc_zerorpc.py acts as a client that has a parent process and 3 subprocesses spun up via gipc. These clients just attempt to connect to the zerorpc_server and call its getpid() method.

When running gipc_zerorpc.py as it currently stands in the repository, the subprocesses are all successfully able to connect to the server and print its PID. However, when uncommenting line 10 so that the parent process also creates a zerorpc client connecting to the zerorpc_server, the parent process successfully calls zerorpc_server.getpid() but the child subprocesses get a "Lost Remote".
You can start gipc_zerorpc.py via `pipenv run python -m gevent.monkey gipc_zerorpc.py`.

I’m pretty sure being able to run zerorpc clients in both the parent and subprocesses is possible and I’m just unaware of some fundamental piece of understanding that’s causing this issue.

Would love if anyone who knows about this area could share and let me know what I’m missing, thanks very much in advance!

[François-Xavier Bourlet]

Thanks for the complete test repo! No promise, but I will try to look
at it over the weekend.

You shouldn't have to monkey patch, since gipc and zerorpc are both
using gevent.

> --
> You received this message because you are subscribed to the Google Groups "zerorpc" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to zerorpc+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/zerorpc/a3a34d40-2eb2-4008-b9c7-c679f7643f2e%40googlegroups.com.

[François-Xavier Bourlet]

I believe your problem is because you use zmq before you fork. Let me explain:
- zerorpc uses pyzmq
- pyzmq, when possible, uses libzmq which is a C library
- libzmq uses C threads to process IOs.
- forking after zmq threads are created can often lead to deadlocks

When you call rpc_runner, you are using zerorpc which in turns initializes zmq.
After that, when you start subprocesses, you are technically forking
your own process. Which happens to fork everything, including all the
threads. As far I as know; on posix; its not really well defined what
happens when you fork with threads.

If you instanciate a new zmq context you will workaround the problem.
zerorpc follows the same principle and let you instanciate context
wrapping zmq.

This should workaround the problem:

diff --git a/gipc_zerorpc.py b/gipc_zerorpc.py
index fd2592a..e79de0d 100644
--- a/gipc_zerorpc.py
+++ b/gipc_zerorpc.py
@@ -7,7 +7,7 @@ class GipcZerorpcTest:
def __init__(self):
self._parent_state = 100
# Uncommenting this line causes child subprocesses
zerorpc_client to hang.
- # self.rpc_runner(0)
+ self.rpc_runner(0)
self.subprocess_initializer()

def subprocess_initializer(self):
@@ -21,8 +21,9 @@ class GipcZerorpcTest:
print("Finished!")

def rpc_runner(self, input):
+ ctx = zerorpc.Context()
print(f"Subprocess started with PID: {os.getpid()} and
subprocess ID: {input} with parent state: {self._parent_state}")
- zerorpc_client = zerorpc.Client()
+ zerorpc_client = zerorpc.Client(context=ctx)
zerorpc_client.connect("ipc:///tmp/test_zerorpc_server.sock")
print(f"ZeroRPCServer PID: {zerorpc_client.getpid()}")

I encourage you to fork BEFORE using zerorpc, but its up to you.

[Han Chang]

Perfect, this did the trick, thanks so much for your help!

> > To unsubscribe from this group and stop receiving emails from it, send an email to zer...@googlegroups.com.