On 12/8/2011 6:22 PM, Chuck Remes wrote: > On Dec 8, 2011, at 6:14 PM, Francois-Xavier Bourlet wrote: > >> You don't need to call recv right after any send, but when you want to >> receive something, you need to call recv before trying to wait for any >> events. In the case recv failed with a tryagain error, you can then >> wait for an event. > This isn't correct. You should be able to call zmq_poll() on the socket and > detect any read/write events. > > ZMQ_FD is a bit tricky. Even if it returns that there was an event, you > *must* check the socket with ZMQ_EVENTS to determine if it was a read or > write event. Sometimes it is neither because the library uses that FD to > signal some internal things too. That's why it is important to check the > event with ZMQ_EVENTS. > > Also, as Francois correctly stated earlier in this thread, zmq_poll() is edge > triggered. What this means in practice is that once you receive an event on a > socket, you *must* process all *messages* on that socket before zmq_poll() > will trigger it again. > > cr I guess there is a difference in behavior to how ZMQ_FD works and zmq_poll. When using ZMQ_FD I don't even get the signal if I don't call recv first (the timing doesn't matter, I can send out a reply 10 seconds later and I still won't get a notification on the ZMQ_FD unless I've called recv before.
Another thing is that calling recv on a ZMQ_REQ socket that I've already recv'd from, even if NOBLOCK is enabled, will return EFSM. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
