That's make the code quite more complex to keep the exact same code path. We need to go back to the old three cases (Windows, MSG_DONTWAIT and pure BSD) when timeout is -1, as well as to handle the MSG_DONTWAIT special case when timeout != -1. I will do that, but I'm not sure it worth the added complexity. May be we could instead work on an optimized internal version of zmq_poll for our special case (single socket, always the same with the same option) ?
Fabien 2011/6/12 Martin Sustrik <[email protected]>: > On 06/12/2011 01:53 AM, Fabien Niñoles wrote: >> >> OK, I add a test for this condition, find a bug in my previous code >> and fix this. Nothing better than a test to check your work :) >> >> Here the new patch. > > Great! > > Now for the performance stuff. Can you fall back to the old wait mechanism > (simple blocking recv call) in case the timout is infinite. The point being > that calling recv is much faster than calling zmq_poll followed by recv. > > That way there would be no performance regression for those using the API in > the old way and thus we can merge the patch in straight away. > > The new way (RCVTIMEO/SNDTIMEO) will be somehow slower but we can fix that > later on. > > Martin > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
