[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-meisters] Restart of apache required

From: Peter Bex
Subject: Re: [Chicken-meisters] Restart of apache required
Date: Wed, 11 May 2011 13:25:25 +0200
User-agent: Mutt/

On Wed, May 04, 2011 at 05:57:16AM -0400, Felix wrote:
> > switching to #<thread: thread181594>
> > #<thread: thread181594> blocks for timeout -2147409012.0
> > ##sys#thread-block-for-timeout!: invalid timeout
> > [] 
> > ...more...
> > 
> > What's going on?
> A negative timeout value.

Not just negative, but it's a flonum, too!  That's because this is about
twice as large as the most positive fixnum on call-cc:

#;1> (- (* most-positive-fixnum 2) 2147409012.0)

That indicates a possible overflow to me.

> This seems to happen from time to time, I
> don't know the reason for this. The places where this procedure is
> called are the srfi-18 API functions, so this already is an invalid
> argument passed to library functions. There are some lowlevel eggs
> like sendfile that call these internal blocking-procedures, IIRC, and
> there also incorrect timeout-argument values are possible.

AFAICT, sendfile has the following idiom *everywhere* it sleeps:

(when (write-timeout)
   (+ (current-milliseconds) (write-timeout))))

Is this correct?  As far as I can see, because write-timeout is
a parameter it should be thread-local so there should be no race
condition between the "when" check and the block-for-timeout call.

Is it possible that after a program is running for a long time,
current-milliseconds produces an overflow?

Turns out this can happen, after hacking a bit:

address@hidden:~$ gdb /usr/local/chickens/chicken-safer-scheduler-debug/bin/csi 
(gdb) run
Starting program: /usr/local/chickens/chicken-safer-scheduler-debug/bin/csi 

(c)2008-2010 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.6.0rc1 (safer-scheduler)
linux-unix-gnu-x86 [ manyargs dload ptables ]
compiled 2010-09-18 on hd-t1179cl (Linux)

#;1> ^C
Program received signal SIGINT, Interrupt.
0xb7f3e424 in __kernel_vsyscall ()
(gdb) set C_startup_time_seconds=0
(gdb) c

Of course this is an extreme case and I can't seem to get it to overflow
when I plug in values that are more realistic (like 3600*24*56, the number
of seconds between March 9th (date of previous restart) and May 4th).

On the other hand, when I call current-seconds, it returns a greater
number (is that right?) and it does go into flonum mode immediately
on startup:
#;2> (current-seconds)

I don't immediately see anywhere that's being used though.

"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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]