On 4 May 2012 07:00, Keith Browne <tuxedo@...> wrote:
> The failure we're seeing is happening when we're connecting to an SBCL instance
> using Emacs and SLIME. We've run some tests in which we run SBCL directly from
> the shell, and we haven't seen a failure in that case. The problem may be
> related to signal handling when SLIME/SWANK is running.
> When we're just running a handful of timers that keep rescheduling themselves
> every few seconds, we can run our application for days or weeks before we see a
> failure. When one timer fails, though, it seems to take all the rest of the
> timers in the image with it--also suggestive of a problem in signal handling.
> We've run test cases with hundreds or even thousands of timers turning over at
> once, and in those cases we can usually see a failure within minutes, or an
> hour to two hours.
> Some sample code demonstrating the problem with recurring timers is available
> at http://www.deepsky.com/~tuxedo/exercise-timers.tar.gz.
> Is this a known problem with the timer implementation in SBCL? In order to be
> certain that our application won't stop executing timer-related callbacks,
> should we have a dedicated thread that sleeps and periodically wakes up to
> reschedule all the timers? Or an external process that tickles our Lisp
> program for the same purpose?
No, this is not a known problem -- or at least it doesn't ring any
bells for me. I have your test running here, and will try to
A few extra questions:
- SBCL version?
- Output from uname -a?
- How exactly are you running the test? You say you connect to SBCL:
do you mean just M-x slime, or do you have SBCL already running with a
swank server that you connect to?