Re: [Xen-API] timing loops

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

How do you decide on a reasonable value of n, given that real timeouts shift so 
dramatically with dom0 system load?  Or rather, what areas of xapi aren't fully 
event-driven and require such timeouts? 

I can imagine the device/udev layer being icky in this regard, but a good way 
to wrap all such instances might be to have a single event-dispatch daemon 
which combines all the system events and timeouts, and coordinates the 
remainder of the xapi process cluster (which will not need arbitrary timeouts 
as a result).  Or it just too impractical since there are so many places where 
such timeouts are required?

-anil

On 10 Jul 2012, at 15:18, Dave Scott wrote:

> 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
> Xen-api@xxxxxxxxxxxxx
> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
> 


_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api