[zeromq-dev] What is the canonical handling of zeromq sockets when fork+exec?

[zmqdev]

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?!