[zeromq-dev] How should sockets be destroyed?
Laurent Alebarde
l.alebarde at free.fr
Mon Feb 24 11:43:23 CET 2014
Where is your socket variable declaration ?
You shall use one variable per socket, so, use an array.
Le 24/02/2014 11:32, Olaf Mandel a écrit :
> Hello,
>
> I am currently trying to open and close many sockets and run into the
> MAX_SOCKETS limit, even though only one socket should be open at a time.
> Basically I do (return value checks removed for readability):
>
> int const l = 0;
> int i;
> for(i=0; i<10000; ++i) {
> socket = zmq_socket(context, ZMQ_REP);
> rc = zmq_setsockopt(socket, ZMQ_LINGER, &l, sizeof(l)); /* #1 */
> rc = zmq_connect(socket, "inproc://demo");
> rc = zmq_close(socket);
> }
>
> The socket creation fails in zmq::ctx_t::create_socket() at
> if(empty_slots.empty ()) { /*fail*/ } .
> Note 1: The presence or absence of zmq_setsockopt() makes no difference.
>
>
> When trying to figure out what happens on zmq_close(), I run into
> zmq::socket_base_t::check_destroy(), which never seems to do anything.
> It simplifies down to the following:
>
> if (destroyed) { // set by zmq::socket_base_t::process_destroy()
> /*destroy fd and socket, send notification to preaper*/
> zmq::own_t::process_destroy();
> }
>
> Here socket_base_t::process_destroy() is a virtual overload of
> own_t::process_destroy(), and it seems to be called from a single place:
> zmq::own_t::check_term_acks() . But I lack the background to understand
> this if-statement which is never true:
>
> if(terminating && processed_seqnum == sent_seqnum.get () &&
> term_acks == 0) {
> /* ... */
> process_destroy();
> }
>
>
> So my question boils down to: is this expected behaviour and I am doing
> something wrong (like failing to call another close-function in addition
> to zmq_close()) or is this a known or new bug in ZMQ?
>
> Thanks for any insight,
> Olaf Mandel
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140224/ac392737/attachment.htm>
More information about the zeromq-dev
mailing list