Sorry forgot to mention, exec itself is not possible. Child-child executes from a different piece of code from where child has left. And in parallel child executes a different code.
Thanks, Selim On Thu, Sep 12, 2013 at 2:35 AM, Michi Henning <[email protected]> wrote: > 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 >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
