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 <[email protected]> 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 > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > 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
