[zeromq-dev] socket writability and events

[Justin Karneges]

Ok some quick testing within my app confirms that EAGAIN will be returned if a 
socket turns out to be unwritable, even after indicating writability. For 
example, if a tcp connection is established, POLLOUT is indicated, the tcp 
connection is broken, and then a write is attempted.

Personally I think this is fine. I'd rather know that the socket is unwritable 
rather than the alternative which would be to eat the message. It is a bit of 
a "gotcha" though, for anyone used to internet sockets (or pipes in general), 
where if a socket is said to be writable then this condition cannot be revoked 
(well, I suppose that's not quite true, we have the lovely EPIPE there 
instead).

Also, this I think this can only ever happen with bind sockets. So the 
behavior could go away someday if bind sockets ever get their own outbound 
queues that live independent of peer connections.

As for part 2: it seems the unavailablity of writes is actually notified via 
ZMQ_FD through the lack of POLLOUT being set in the events. I'd never 
considered taking action by the absense of this flag until now. This means my 
app learns about unwritability immediately and the window of opportunity to 
write to a socket that is no longer unwritable becomes very very small. I also 
believe this means it is unnecessary to poll the events after a failed 
zmq_send.

On Friday, December 14, 2012 11:46:09 PM Pieter Hintjens wrote:
> Part 1. the behaviour isn't documented but what you suggest makes
> sense. You should be able to reproduce it.
> 
> Part 2. not documented, again, would need to test to be sure.
> 
> Once we have reproducible cases we can see whether these are bugs to
> fix, or expected effects to document.
> 
> -Pieter
> 
> On Fri, Dec 14, 2012 at 9:40 PM, Justin Karneges <justin at affinix.com> wrote:
> > Hi,
> > 
> > Is it possible that a socket could be determined to be writable but then
> > actually isn't writable at the time of write? For example, say a
> > connection
> > exists on a bind socket and ZMQ_POLLOUT is indicated. But then just before
> > calling zmq_send(), the connection is destroyed. A socket that was using
> > bind should have no queue anymore, and therefore I would expect the send
> > to actually block (or report EAGAIN). I just want to confirm this is
> > indeed possible.
> > 
> > Secondly, assuming the above is true, if you're doing an event loop
> > integration and checking ZMQ_EVENTS after every call to zmq_send, do you
> > still need to check the events even if zmq_send fails? My guess is that
> > if it fails with EAGAIN, that you probably should check the events
> > (especially if the reason you attempted a write in the first place is
> > because ZMQ_POLLOUT was indicated prior). What I'm doing in my code now
> > is checking events after success or EAGAIN, but not checking in any other
> > case. Looking for confirmation on this as well.
> > 
> > Thanks,
> > Justin
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev