Hi, With all the recent xapi disaggregation work, are we now more vulnerable to failures induced by moving the system clock around, affecting timeout logic in our async-style interfaces where we wait for 'n' seconds for an event notification?
I've recently added 'oclock' as a dependency which gives us access to a monotonic clock source, which is perfect (I believe) for reliably 'timing out'. I started a patch to convert the whole codebase over but it was getting much too big and hard to test because sometimes we really do want a calendar date, and other times we really want a point in time. Maybe I should make a subset of my patch which fixes all the new timing loops that have been introduced. What do you think? Would you like to confess to having written: let start = Unix.gettimeofday () in while (not p && (Unix.gettimeofday () -. start < timeout) do Thread.delay 1. done I've got a nice higher-order function to replace this which does: let until p timeout interval = let start = Oclock.gettime Oclock.monotonic in while (not p && (Int64.(to_float (sub (Oclock.gettime Oclock.monotonic) start) / 1e9) < timeout) do Thread.delay 1. Done I believe this is one of many things that lwt (and JS core) does a nice job of. Cheers, Dave _______________________________________________ Xen-api mailing list [email protected] http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
