Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 15 Mar 2013 00:15:05 +0100
From: magnum <>
Subject: Re: clock err in timers (alarm, status ...) and fix

On 14 Mar, 2013, at 22:08 , magnum <> wrote:
> On 14 Mar, 2013, at 19:37 , Solar Designer <> 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.


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.