Hi Brian, > I have a simple event loop that is doing non-blocking IO using > s.recv(NOBLOCK) and Poller.poll. I am seeing the following behavior > that might be a bug: > > * I am using a REQ socket that connects to a REP socket. > * I do a send right after calling connect. > * Then I enter a loop to watch for replies. The first few times that > I call poll (watching POLLIN) it returns immediately with an empty > poll set. This is true > even if I provide a rather large timeout (1 second for example). > * After a short while (maybe a second or so) the poll calls do get > longer and if they are short, they return a non-null poll set. > > Is this a bug? What should poll do with a socket that is still connecting?
No, it's not a bug. The first events you see are actually some internal messages from I/O thread managing the connecting to your application thread. What timeout you set doesn't matter, because your application cannot obviously process those internal messages while it is sleeping. If you use infinite timeout, 0MQ will hide these internal events from you. The problem with non-infinite timeout is that zmq_poll would have to call gettimeofday each time it is called, so that in case of internal event it would be able to compute the remaining time to wait. This would have an impact on performance. (Actual impact wasn't measured yet. It will differe between OSes depending on how efficiently is gettimeofday implemented.) May thinking ATM is that in 2.1 this gettimeofday stuff should be done in zmq_poll -- thus making it honour timeouts. Those that are interested in extreme performance would still be able to use ZMQ_FD and ZMQ_EVENTS socket options combined with native poll functions. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
