Matt, I made a correction to an ignorant statement of mine in that quoted text. Unless I'm mistaken there's 2 options for a user, set the timeout to 0 and do their own looping and time checking, or use 0mq's timeout. If they choose 0mq's timeout, 0mq's poll() blocks, so it can safely defer its time checks, using an initial average frequency and worst-case (longest) interval from a sufficient number of initial checks, to far below any conceivable or physical possibilities for any overshoots. The user can't interrupt poll() once they've called it with a timeout, whether infinite or finite.
On 4 September 2010 23:10, Matt Weinstein <[email protected]> wrote: > > > 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 > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
