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

[Chuck Remes]

On Jul 8, 2010, at 6:55 AM, Matt Weinstein wrote:

> 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.

I think this is a reasonable suggestion. Right now there is no way to check 0mq for queued messages, queue depth, pending I/O, etc. A mechanism to do so would be nice.

I'm not in favor of adding more blocking behavior to the system. I prefer everything to be asynchronous so that I can tend to other work. Blocking behavior ruins my throughput.

Flushing messages from closing sockets (or terminated contexts) is only interesting at the final stage of an application's lifecycle. Earlier in this thread someone mentioned that it's probably a buggy "pattern" if one is opening and closing lots of sockets during a program's lifetime. I agree.

cr