Date: Sun, 24 Oct 1999 09:52:21 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Sergey Vlasov <vsu AT au DOT ru>
cc: djgpp-workers AT delorie DOT com
Subject: Re: [vsu AT au DOT ru: bugs in itimer.c]
In-Reply-To: <005b01bf1c99$90901940$0201a8c0@center1.mivlgu.ru>
Message-ID: <Pine.SUN.3.91.991024095201.29385g-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Fri, 22 Oct 1999, Sergey Vlasov wrote:

> It seems that I have found the source of this problem. The conversion from
> uclocks to microseconds in getitimer() calculates the tv_usec field as
> uclk*3433/4096 (here uclk = expire % UCLOCKS_PER_SEC). When uclk == 1193179
> (the maximum value, UCLOCKS_PER_SEC-1), this gives 1000044, because the
> coefficient values 3433 and 4096 are not precise.

Yes, I think you are right.

> I have performed some optimization using `asm' to increase the speed.
> Calculating (uclk*1000000/UCLOCKS_PER_SEC) does not need to return a 64-bit
> result -- only the intermediate value needs to be 64-bit wide. Using
> 32*32->64 expanding multiplication and 64/32->32 division saves both time
> and space.

Thanks.

I tend to include this change in the current CVS sources, but I'd like
to give it some more testing.  If you can download the latest
djtst203.zip (from the alphas directory on one of the usual DJGPP
sites), run the test programs in the tests/libc/posix/signal and see
if they still behave the same (or better) with the new version, that
would be swell.  If not, I'll do it when I have time.

> Maybe setitimer() should be changed to use the more precise version also,
> so that getitimer() and setitimer() will have identical behavior?

Yes.  Please change setitimer also, to use the same conversion.