[zeromq-dev] zmq_close() semantics and handling outstanding messages

Matt Weinstein matt_weinstein at yahoo.com
Thu Jul 8 13:55:31 CEST 2010


IMHO the least surprising close semantics depend on the class of socket.

For example, REQ/REP or PAIR should not bother to flush, because they  
are a communicating "pair" (temporal/ry or not), and if the  
correspondent has gone away, that's probably more important.
STREAM sockets probably should finish, PUB sockets should probably  
finish.  etc.

A more important is that whereas TCP is in the kernel, ØMQ is not, and  
their lifetimes are different, which means you could still close(),  
then exit() from another thread, and it would be an unpleasant  
"surprise" if you expected close() to finish sending, and it didn't.

Right now, I'd say the simplest way might be to add a way of finding  
out if a socket is "busy" doing stuff you asked it to, which allows  
you to wait if you want to.  You could do this e.g. by adding  
getsockopt(ZMQ_IOPEND).

Then you can hang around waiting for completion:

for (;;) {
int64_t working;
int rc = zmq_getsockopt (psocket, ZMQ_IOPEND, &working, sizeof working);
assert (rc == 0);
if (! working) {
	rc = zmq_close(psocket);
	assert(rc == 0);
	break;
}
usleep(10000);
}

Obviously this can be wrapped, error checked, etc.

On Jul 8, 2010, at 5:38 AM, Pieter Hintjens wrote:

> On Thu, Jul 8, 2010 at 11:19 AM, Martin Lucina <mato at kotelna.sk>  
> wrote:
>
>> Almost any UNIX system call can return EINTR if it's interrupted at  
>> just
>> the right time, that doesn't make it a blocking call.
>
> If it does almost nothing, then blocking and non-blocking are the
> same... close() is synchronous even if it does nothing.  fclose()
> flushes data and that could conceivably block exactly as I'm
> suggesting zmq_close() would block, if it flushed messages to the OS.
>
> Given that we don't have any scenarios that prove or disprove this
> solution, it's pretty irrelevant.  We need to flush messages at some
> stage before exiting the process, and we need to add this without
> changing the API.
>
> Opinions from others would be welcome.  Does a zmq_close() which
> flushes pending messages make sense?  Or is that too surprising?
>
> I'm sure when Sustrik gets back from his week off he'll have a good
> answer to this :-)
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list