[email protected] said: > > 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.
Well, it's leakage of 0MQ internal events into the zmq_poll () API, so I'd call it a bug in the zmq_poll () implementation. > 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. +1 and I've been meaning to do this for 2.1 when I rewrote the zmq_poll () code there, just haven't had time to do so yet. > 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. How would that get you better performance? You'd still have to deal with the case where ZMQ_FD would become ready and ZMQ_EVENTS would return nothing due to an internal 0MQ event being triggered. -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
