> Oops, one more thing. Why do you need 250 msecs? Say, why 500 msecs? > Even if add_work() argument is second accuracy, as I wrote. > As i wrote previously: > There are 3 different sources of inaccuracy. > The first one is related to the random distribution of add_work() calls > within the 250 (or whatever) msec timer interval. The second one is related > to the random distribution of work expiration times within the 250 msec > timer interval. These are bounded by 250 ms, averaging in 125 msec each. > ... > In your patch the big inaccuracies are doubled and no alleviation as above > is provided. This means that if you use 500ms then the inaccuracy may be up to 1sec, averaging in 500ms. When the user asks timeouts in seconds resolution, the acceptable accuracy should be sub-second, say, maximum half-a-second, shouldn't it? For example when 2 sec is requested but actually it may get anywhere between 1s and 3s. Using 250 msec gets 0.5s inaccuracy bound, which would be acceptable. > > As I wrote, I don't want to add gettimeofday for the timerfd approach > > but using gettimeofday for this signal approach is fine by me. > > > > One thing I want to change in your previous patch is using 'unsigned > > int when' in tgt_work struct instead of struct timeval. It allows the > > timerfd and signal appoaches to share that. The signal appoach can > > convert struct timeval to unsigned int current_time. Sounds good! I really missed the point about unreliable signals delivery. The 3 first patches also look ok and do compile. > I did by myself. Alexander, can you check if this works for you. It won't work on older kernels because you include <timerfd.h> unconditionally (relying only on timerfd_create return value) but there is no such header file with those kernels, so timerfd_create() is not exported. I'm going to send a modified patch which checks for timerfd pre-processor symbol. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
