On Fri, 2016-11-25 at 12:22 +0100, zmqdev wrote: > 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?!
Yes I suspect the background I/O thread suddenly going missing might have caused issues. Did setting the linger and closing the socket help? Kind regards, Luca Boccassi
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list firstname.lastname@example.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev