[zeromq-dev] duped sockets and fork

[Michi Henning]

How about having the client exec itself after a fork, with the close-on-exec flag set? That would give each forked client a clean slate to start with.

Michi.


On 12/09/2013, at 19:29 , Selim Ciraci <ciraci at gmail.com> wrote:

> Hi,
> 
> We have client/server program, the server is a process itself that is started separately from the client. The client on the other hand from time to time forks workers (we have to use fork because we are parallelizing a huge piece of code that is not thread safe at all). After forking the initial client also does some work and then checks its children. 
> The child processes, immediately after forking create a context and open connection to the server. 
> The childern themself can form new processes. These 'child-child' processes also create a context and open connections to the server.
> Now the problem is that fork caries the parent sockets to the children. This means that a child-child-child-child... process can end up with too many open sockets such that opening more sockets are not possible In fact in this case, Zmq aborts with too many open sockets in signaler.cpp:230. The question is how can close parent sockets safely from child? (I cannot use zmq_ctx_destory with parent context)
> I read about certain 'hacks' that read the fds from /proc and close them one by one. The problem with this solution is that I don't know which fds are sockets, I might end up closing an fd used for file operations.
> Zmq sockets are void*. is there a way to get the low level descriptor from these void* sockets? 
> Any suggestions to fix this problem? I'm stuck with fork and I cannot change the architecture.
> 
> Thanks!
> Selim Ciraci
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev