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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
