[Ecls-list] Problems with slime

[Tobias C. Rittweiler]

"Tobias C. Rittweiler" writes:

> "Tobias C. Rittweiler" writes:
>
>> Juan Jose Garcia-Ripoll writes:
>>
> >> Slime gets my computer at 100% activity because it has some strange way of
> >> waiting for input: this is a loop over streams, inifite, using
> >> read-char-no-hang without ever waiting. I am sure there are better ways of
> >> doing this. This is in swank-backend.lisp -- do all implementations have
> >> this problem?
> >>
> >> (defun wait-for-streams (streams timeout)
> >>   (loop
> >>    (when (check-slime-interrupts) (return :interrupt))
> >>    (let ((ready (remove-if-not #'stream-readable-p streams)))
> >>      (when ready (return ready)))
> >>    (when timeout (return nil))
> >>    (sleep 0.1)))
> >
> > The problem is that not more advanced ways are implemented. Slime can
> > also me made to use threads, and serve-event, but ECL's backend does not
> > support that.
> >
> > I tried to do both in past, but encountered non-obvious problems. I'll
> > polish up, and commit the work in progress.
>
> OK, juanjo, I committed the work in progress.

Attaching gdb, and extracting the (full) backtrace for swank's control
thread which is waiting, I get:

  (gdb) info threads
  * 3 Thread 0xb7027b70 (LWP 16194)  0x002a0422 in __kernel_vsyscall ()
    2 Thread 0xb7828b70 (LWP 16195)  0x002a0422 in __kernel_vsyscall ()
    1 Thread 0xb78296d0 (LWP 16176)  0x002a0422 in __kernel_vsyscall ()

  (gdb) backtrace
  #0  0x002a0422 in __kernel_vsyscall ()
  #1  0x0037abd3 in ?? () from /lib/tls/i686/cmov/libc.so.6
  #2  0x003018bf in ?? () from /lib/tls/i686/cmov/libc.so.6
  Backtrace stopped: previous frame identical to this frame (corrupt stack?)

  (gdb) info frame
  Stack level 0, frame at 0xb7022e28:
   eip = 0x2a0422 in __kernel_vsyscall; saved eip 0x37abd3
   called by frame at 0xb7022e38
   Arglist at 0xb7022e20, args: 
   Locals at 0xb7022e20, Previous frame's sp is 0xb7022e28
   Saved registers:
    eip at 0xb7022e24


LWP 16194 is the control thread. I hacked ECL locally so it includes
the LWP identification in the print representation of threads:

  > (mp:all-processes)

  (#<process "reader-thread" (LWP 16195) 09e12f88>
   #<process "control-thread" (LWP 16194) 09e12fc0>
   #<process SI:TOP-LEVEL (LWP 16176) 092c5fc0>)

Does this make any sense to you?

  -T.