On 25.11.2016 11:50, Luca Boccassi wrote:
What I can say is that we have a unit test for this situation:
https://github.com/zeromq/libzmq/blob/master/tests/test_fork.cpp
And the child closes the (TCP) socket explicitly before the context.
Which is in fact what should happen in all cases.
The parent then can receive messages on the sockets just fine.
Maybe it's a linger issue? By default a socket has 30s of linger grace
period.
Try setting ZMQ_LINGER to 0 in the socket in the child, close the socket
and then terminate the context perhaps.
thanks. Formatted differently:
1. zmq_close sockets in child (perhaps setting ZMQ_LINGER to 0
beforehand)
2. zmq_term context in child
and only then
3. close rest of file descriptors in child
The reason I went directly to point 3 is this line from the man page of
fork(2):
The child process is created with a single thread—the one
that called fork().
(see http://man7.org/linux/man-pages/man2/fork.2.html)
Michael Kerrisk in "The Linux Programming Interface" insists:
When a multithreaded process calls fork(), only the calling thread is
replicated in the child process. (The ID of the thread in the child
is the
same as the ID of the thread that called fork() in the parent.) All
of the
other threads vanish in the child; no thread-specific data
destructors or
cleanup handlers are executed for those threads.
(...)
Of course, that's where I run into the problem?!
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
