On Sep 4, 2010, at 3:58 AM, Martin Sustrik wrote: > Naveen, > >> And if you want to be really safe, you can make it a "LOOP_OPTIMIZED" >> option, where the user knows that prematurely breaking from a polling >> loop with a timeout causes that timeout value not to be honoured >> correctly, and to use the "fail-safe" version to be certain. The >> "fail-safe" version can be enabled by default or vice versa. > > We've been trying to get rid of such magic options in 0MQ. Too much of > them and the product becomes unusable... :( > > I think we'll have to stick with time measurement per zmq_poll call > and > allow users to create optimised algorithms -- such as one you've > proposed -- via ZMQ_FD and ZMQ_EVENTS socket options. >
On the other hand... It is trivial for the user to wrap a time test around zmq_poll(), but non-trivial for the user who doesn't want it to remove it. IMO wakeup conditions are the user's responsibility, time just happens to be a condition here. Not to mention -- time checks are difficult to get right, e.g. you need stable time (e.g. CLOCK_MONOTONIC), clocks vary wildly across environments, not to mention running under virtualization, non-synced cores, ... I suggest offering a wrapper e.g. zmq_poll_clock() in an external library (non-core ØMQ) just like the performance routines, and let experience drive additional functionality... Best, Matt > Martin > _______________________________________________ > 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
