Re: [slime-devel] feture suggjestion
OK, then I'll try to implement it, when I get time. (which will not be before the end of July, if not then, then next year. I hope someone has more time for this than I :) killing threads in a infinite loop is like killing any other thread. slime-list-threads (C-c C-x t) then arrow up and down to your (un)favorite thread of choice, then press "k". On 6/23/05, Jeffrey Cunningham <jeffrey@cunningham.net> wrote:
I like it. Incidentally, how do you kill any thread caught in an infinite loop? I've been trying to figure this out for sometime.
--Jeff Cunningham
On Thu Jun 23, 2005 at 12:02:06PM +0200, Knut Olav B?hmer wrote:
When I'm in a buffer editing my lisp-code, and decide to test the code, by pressing C-x C-e, slime forks of a new thread with the name "worker". The problem starts when I have several threads running from different buffers with the name "worker", and one of the threads ends in an infinite loop or deadlock, and I want to kill one of the threads. Then I don't know which thread is doing what.
So If the thread got the name "worker + buffer name" then I would have slightly more control.
Good Idea?
-- Knut Olav Bøhmer tlf: +47 47400777 _______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
--Jeff
-- Knut Olav Bøhmer tlf: +47 47400777
Knut Olav Bøhmer <bohmer@gmail.com> writes:
killing threads in a infinite loop is like killing any other thread. slime-list-threads (C-c C-x t) then arrow up and down to your (un)favorite thread of choice, then press "k".
now I'm confused. I typed the following in a buffer named foo.lisp: (defun endless () (endless)) (endless) After the defun, I did C-c C-c and after the (endless) C-x C-e. CPU load goes to 100% as expected, but C-c C-x t only shows 1: Initial Run and no other threads. Superior lisp is Cmucl in my case. What implementation are you using?
On Thu Jun 23, 2005 at 12:02:06PM +0200, Knut Olav B?hmer wrote:
[ threads named 'worker']
So If the thread got the name "worker + buffer name" then I would have slightly more control.
"worker + buffer name 2" might be good if you want to distinguish between threads started from the same buffer. Goodbyte, Gerd. -- The last thing one knows in constructing a work is what to put first. -- Blaise Pascal
On 6/23/05, Gerd Flaig <gefla@pond.sub.org> wrote:
Knut Olav Bøhmer <bohmer@gmail.com> writes:
killing threads in a infinite loop is like killing any other thread. slime-list-threads (C-c C-x t) then arrow up and down to your (un)favorite thread of choice, then press "k".
now I'm confused. I typed the following in a buffer named foo.lisp:
(defun endless () (endless))
(endless)
After the defun, I did C-c C-c and after the (endless) C-x C-e. CPU load goes to 100% as expected, but C-c C-x t only shows
1: Initial Run
and no other threads. Superior lisp is Cmucl in my case. What implementation are you using?
Infinite loop, does not automatically imply tight loop. I did not try with a tight loop. One minute and I'll see........ (do ((foo nil)) (foo nil) (setf foo nil)) No problem, but I don't know if the rutine is representative. At work I'm running lispworks. I eaven tryed forking off 4 of them. And still ok.
On Thu Jun 23, 2005 at 12:02:06PM +0200, Knut Olav B?hmer wrote:
[ threads named 'worker']
So If the thread got the name "worker + buffer name" then I would have slightly more control.
"worker + buffer name 2" might be good if you want to distinguish between threads started from the same buffer.
There is already a incremental number involved (thread-number). -- Knut Olav Bøhmer tlf: +47 47400777
Gerd Flaig <gefla@pond.sub.org> writes:
Knut Olav Bøhmer <bohmer@gmail.com> writes:
killing threads in a infinite loop is like killing any other thread. slime-list-threads (C-c C-x t) then arrow up and down to your (un)favorite thread of choice, then press "k".
now I'm confused. I typed the following in a buffer named foo.lisp:
(defun endless () (endless))
this, under certain compiler optimizations, will overflow the stack.
(endless)
After the defun, I did C-c C-c and after the (endless) C-x C-e. CPU load goes to 100% as expected, but C-c C-x t only shows
1: Initial Run
and no other threads. Superior lisp is Cmucl in my case. What implementation are you using?
you didn't create a new thread here. you've sent your only thread into an infinite loop (whcih isn't a great idea). try something like this: (mp::startup-idle-and-top-level-loops) ; not need if you're running under slime (mp:make-process (lambda () (loop)) :name "kill me now") -- -Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Knut Olav Bøhmer <bohmer@gmail.com> writes:
When I'm in a buffer editing my lisp-code, and decide to test the code, by pressing C-x C-e, slime forks of a new thread with the name "worker".
"Marco Baringer" <mb@bese.it> writes:
[ C-x C-e ]
you didn't create a new thread here. you've sent your only thread into an infinite loop (whcih isn't a great idea).
ah. That explains why I didn't find anything relating to thread creation in the code implementing C-x C-e. ;) Goodbyte, Gerd. -- The last thing one knows in constructing a work is what to put first. -- Blaise Pascal
On 6/23/05, Gerd Flaig <gefla@pond.sub.org> wrote: <cut>
now I'm confused. I typed the following in a buffer named foo.lisp:
(defun endless () (endless))
(endless)
After the defun, I did C-c C-c and after the (endless) C-x C-e. CPU load goes to 100% as expected, but C-c C-x t only shows
1: Initial Run
and no other threads. Superior lisp is Cmucl in my case. What implementation are you using?
Hmm. Now I also tried with cmucl, and it looks like it does things in a very different way then with lispworks. First of all, it looks like it's not able to fork of one thread for each slime-eval-last-expression, so this feature is useless on this implementation. btw. I already (setq slime-multiprocessing t) Is cmucl not able to do this? I didn't try with sbcl, because I was not able to start it.. <cut> -- Knut Olav Bøhmer tlf: +47 47400777
participants (3)
-
Gerd Flaig -
Knut Olav Bøhmer -
Marco Baringer