Hi Selim,

I have a similar (although simpler) scenario in mind. I discovered that closing 
a zmq context in a forked child context that was inherited from the parent 
would actually crash the parent (assert).

What version of ZeroMQ are you using? If you’re using the head, I have added 
some code to allow this context to be terminated without causing an assert. 
There is a test use case in the file tests/test_fork.cpp.

If not, can you try the development master from github and let me know if this 
helps?

Regards,
Matt


On 12 Sep 2013, at 7:29 pm, 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

Reply via email to