On Fri, Sep 16, 2011 at 09:11:28PM +0200, Petr Salinger wrote:
fail on subsequent runs. Much smaller (order of magnitude) numbers seem ok, and I haven't identified a specific bad number. In a loop, 800000000 seems ok, while 900000000 exhibits intermittant failure. Assuming that holds true, we could set the max timeout to about 25 years (which should suffice for any practical purpose), but that seems like an odd value to choose unless it can be somehow explained and rationalized.May be related to January 19, 2038, aka time_t(0x7FFFFFFF) ? Now, the diff is 831284152.
Ah, now that makes sense. Kinda. It still doesn't explain why the result is random. :-) But I did some more testing and it does seem to fail between 831000000 and 832000000. I suppose it might be reasonable to fail if "interval + time(2) > time_t". OTOH, it might also be better for that checking to be done in the timer_settime code as it seems like a unique failure mode in this particular implementation (rather than having to do that in every application). I suppose that would be a bug/request for eglibc.
Mike Stone