[zeromq-dev] zmq context and child process after fork

Michael Devereaux Michael.Devereaux at quantum.com
Tue Mar 17 13:12:17 CET 2015

I have a question that briefly browsing the zmq 3.2.3 code has not answered for me.

1.       Suppose I have a multithreaded process in which any number of pthreads may have zmq sockets/endpoints performing messaging.

2.       One of those threads - it could be the main thread, could be any of the child pthreads - performs a fork, but does not perform one of the execs.

3.       My question: what is known to be true in the child process' zmq context after the fork?  Specifically, what is the invariant for the zmq context, if the method "child" is called that is registered via pthread_atfork( void (*prepare)(void), void (*parent)(void), void (*child)(void))?

The child process "inherits the entire process space" of the pthread in which fork is called.  That includes the zmq context.  But the parent's zmq context is capable of closing all sockets across all of its pthreads.  The child process inherits only its parent pthread's socket(s) and endpoints.

Which sockets and endpoints does the child process' zmq context "know about"?  If zmq_ctx_term is called within the child process immediately after fork - or in the "child" method registered via pthread_atfork - which sockets will the zmq context attempt to close?  Only those sockets created within the pthread that executed fork()?

Is the better question to ask: In the child process after such a fork, which sockets that the parent process' zmq context had open for all of its threads, remain open within the child process' zmq context?

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150317/cd1a17e5/attachment.htm>

More information about the zeromq-dev mailing list