Re: [Chicken-users] current-time on 32-bit hardware

[Felix]

From: Nicolas Pelletier <address@hidden>
Subject: Re: [Chicken-users] current-time on 32-bit hardware
Date: Fri, 30 Jul 2010 15:09:42 +0900

> 
> I am currently looking at ##sys#schedule. The time-out queue only
> needs to hold time offsets from "now". I suppose the reason for having
> "now" (aka ##sys#fudge 16) sitting around here is to find out whether
> C_msleep slept too long and fire the events the scheduler might have
> missed. But since there are no guaranties from the OS that we will not
> actually sleep a bit too much, I'm thinking of representing the
> current point in time with a plain 0 and replacing (if (>= now tmo1)
> ...) by (if (>= how-much-i-slept tmo1) ...), with how-much-i-slept
> being the time I asked to sleep for.
> 
> I expect thus to be able to still use fixnums to represent time-outs
> while avoiding the "13 days since startup" issue. The maximum for
> time-outs would then be 2**29 ms, or 6 days 5 hours or so, which does
> not sound as a limitation to me.
> 
> Does anybody have any objections to this?

I propose to use flonums for timeout values. This makes the
representation of srfi-18 "time" values simpler and removes any
possibility of overflow. I don't think the performance impact is all
that heavy. Actually, the decision to use fixnums at all costs for
timeout value comparison was a bit of premature optimization on my
side.

If you are adventurous, you can try out the "flonum-milliseconds"
branch in the git repository, where I made all the necessary changes
(quite a lot, in fact). Feedback would be great, since I don't have 
decent testing code for multithreading.

Something will break, that's for sure, but I see no way around it.


cheers,
felix