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 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.
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).
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")
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.
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>
-
Gerd Flaig -
Knut Olav Bøhmer -
Marco Baringer