[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <544725b264f09246b56bee6b2783c882@smtp.hushmail.com>
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.
