Date: Fri, 15 Mar 2013 00:15:05 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: clock err in timers (alarm, status ...) and fix On 14 Mar, 2013, at 22:08 , magnum <john.magnum@...hmail.com> wrote: > On 14 Mar, 2013, at 19:37 , Solar Designer <solar@...nwall.com> wrote: >> On Thu, Mar 14, 2013 at 05:40:53PM +0100, magnum wrote: >>> I applied Costin's changes almost verbatim. Is that not good enough? >> >> The patch looked buggy to me at first glance (where are the timer_* >> variables initialized in accordance with their new meaning? nowhere? >> is the re-initialization via the first += good enough?), but it might >> actually be OK. ... > > I think that simple patch was all there is to it, possibly except this: If a --max-runtime session runs to end and then is resumed, I bet it will immediately abort again since total run time is restored from the session file. I will check that and fix it if needed. That was the case, and the save timer had a similar problem when status_get_time is used. Fixed now. >> Calling status_get_time() every second is a bit wasteful. Perhaps only >> do that when auto-status or auto-abort is requested? >> >> Perhaps not bother with that for auto-save? Or only bother with it for >> auto-save when OS_TIMER is 0 (that is, when the signal handler >> invocation frequency is expected to be very rather than just slightly >> imprecise)? > > Those are all valid points. I will benchmark the impact and have look at the alternatives. Fixed as suggested. I have tried to test all cases with and without OS_TIMER. Everything seems fine now. magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.