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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
