Re: [Chicken-users] current-time on 32-bit hardware
Hi, On Fri, Jul 30, 2010 at 9:13 PM, Felix fe...@call-with-current-continuation.org wrote: 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. Okay, thank you. One thing that still bothers me is the use of gettimeofday inside the scheduler. I'm not sure everything will work nicely if an NTP server (or root) sets the date to something in the past. And then comes the problem of having a _portable_ way to represent monotonic time... 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. Thank you, I'll try it. Something will break, that's for sure, but I see no way around it. Well, it's an experimental branch, after all ;-) -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-users] current-time on 32-bit hardware Date: Thu, 29 Jul 2010 11:01:26 +0200 On Thu, Jul 29, 2010 at 7:12 PM, Felix fe...@call-with-current-continuation.org wrote: Peter Bex peter@xs4all.nl wrote: I'd suggest you use numbers but I don't think thread-sleep! accepts bignums. Felix fe...@call-with-current-continuation.orgreplied: That won't change anything. You are right, and using only small values for timeouts does not help either. No, the reason for this is that the scheduler uses fixnums in timeout checks for performance reasons and because of this, the time objects store time spans as fixnums as well. This will probably have to be changed to use flonums. 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? Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
From: Nicolas Pelletier sxatrxtfxcrwamvjk...@gmail.com 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 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
From: Nicolas Pelletier sxatrxtfxcrwamvjk...@gmail.com Subject: [Chicken-users] current-time on 32-bit hardware Date: Thu, 29 Jul 2010 09:01:46 +0900 Hello, I've run into the following problem. I am taking a mutex with a time-out, as follows: (mutex-lock! children-mutex (seconds-time (+ 1 (time-seconds (current-time) And I got the following error: Warning (#thread: my-thread): : (inexact-exact) inexact number cannot be represented as an exact\ number: 1189553855. I can not reproduce this. On what platform are you running this code? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
Warning (#thread: my-thread): : (inexact-exact) inexact number cannot be represented as an exact\ number: 1189553855. I can not reproduce this. On what platform are you running this code? It is a 32-bit Linux on a Pentium R. If my understanding is correct, the following call is subject to overflow (e.g. inexact-exact is called on a number that would have its bit 30 set if represented as an integer) after the process has been running for running for 12 days 10 hours 15 minutes 41 seconds. So yes, it is not immediately reproducible ;-) (inexact-exact (truncate (+ (* (- s ss) 1000) C_ms))) As a workaround, I can use immediate integers instead of timeout objects in the calls to thread-sleep! and mutex-lock!, at the expense of a few milliseconds time slip. Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
On Thu, Jul 29, 2010 at 05:34:27PM +0900, Nicolas Pelletier wrote: Warning (#thread: my-thread): : (inexact-exact) inexact number cannot be represented as an exact\ number: 1189553855. I can not reproduce this. On what platform are you running this code? It is a 32-bit Linux on a Pentium R. That's why Felix couldn't reproduce it; I'm willing to bet he tried it on 64 bits only. This number cannot be represented as a fixnum on a 32 bit platform, because it requires 31 bits of storage. There are only 30 bits available, because one bit is used as fixnum tag and one bit is taken as the sign bit. I'd suggest you use numbers but I don't think thread-sleep! accepts bignums. Felix: this kind of thing is the primary reason why I think numbers ought to be in Chicken core. As a workaround, I can use immediate integers instead of timeout objects in the calls to thread-sleep! and mutex-lock!, at the expense of a few milliseconds time slip. huh? I don't understand that bit. Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
On Thu, Jul 29, 2010 at 6:01 PM, Peter Bex peter@xs4all.nl wrote: On Thu, Jul 29, 2010 at 05:34:27PM +0900, Nicolas Pelletier wrote: Warning (#thread: my-thread): : (inexact-exact) inexact number cannot be represented as an exact\ number: 1189553855. I can not reproduce this. On what platform are you running this code? It is a 32-bit Linux on a Pentium R. That's why Felix couldn't reproduce it; I'm willing to bet he tried it on 64 bits only. This number cannot be represented as a fixnum on a 32 bit platform, because it requires 31 bits of storage. There are only 30 bits available, because one bit is used as fixnum tag and one bit is taken as the sign bit. Yes. I know this from exchanging data between C and Scheme processes. Values like 0x8000A010 were not going smoothly through at first. I'd suggest you use numbers but I don't think thread-sleep! accepts bignums. For my current needs, I only need small fixnums, so using numbers is enough, and seems like the way to go for an immediate solution. As a workaround, I can use immediate integers instead of timeout objects in the calls to thread-sleep! and mutex-lock!, at the expense of a few milliseconds time slip. huh? I don't understand that bit. I wanted to say the difference in behaviour between the two clocks below, for example, is not an issue for my current program. ; a clock with a gradual drift: (let loop ((x 1)) (thread-sleep! 1) (write x) (loop (+ x 1))) ; a clock with no drift: (let ((start (time-seconds (current-time))) (let loop ((x 1)) (thread-sleep! (seconds-time (+ x start))) (write x) (loop (+ x 1 Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-users] current-time on 32-bit hardware Date: Thu, 29 Jul 2010 11:01:26 +0200 That's why Felix couldn't reproduce it; I'm willing to bet he tried it on 64 bits only. This number cannot be represented as a fixnum on a 32 bit platform, because it requires 31 bits of storage. There are only 30 bits available, because one bit is used as fixnum tag and one bit is taken as the sign bit. The problem is (as Nicolas mentioned) that the time-limit stored in time objects is the number of milliseconds since startup and that overflows a fixnum after 13 days. I'd suggest you use numbers but I don't think thread-sleep! accepts bignums. That won't change anything. Felix: this kind of thing is the primary reason why I think numbers ought to be in Chicken core. No, the reason for this is that the scheduler uses fixnums in timeout checks for performance reasons and because of this, the time objects store time spans as fixnums as well. This will probably have to be changed to use flonums. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] current-time on 32-bit hardware
Hello, I've run into the following problem. I am taking a mutex with a time-out, as follows: (mutex-lock! children-mutex (seconds-time (+ 1 (time-seconds (current-time) And I got the following error: Warning (#thread: my-thread): : (inexact-exact) inexact number cannot be represented as an exact\ number: 1189553855. Looking at srfi-18.scm, the implementation of current-time is: (define (current-time) (let* ([s C_get_seconds] [ss C_startup_time_seconds] [ms C_ms] ) (##sys#make-structure 'time (inexact-exact (truncate (+ (* (- s ss) 1000) C_ms))) s C_ms) ) ) Due to the different representation of integers between C and chicken (32 bits in C, 30 in chicken if I'm not mistaken), the above inexact-exact fails. I am using 4.3.0, but the implementation of current-time in 4.5.0 is the same. On one hand, using 64-bit hardware instead is not an option. On the other hand, I just need mutex-lock! to not wait forever; waiting a little more than one second is okay. Could someone suggest a workaround and/or a fix, please? Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
