-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm using recently updated version of SLIME, CMUCL 19a, CLSQL 3 and Oracle 8.1.7, everything on linux (Red Hat Enterprise Server 3).
I do:
CL-USER> (asdf:oos 'asdf:load-op :clsql-oracle) CL-USER> (use-package :clsql-user) CL-USER> (connect '("SID" "user" "pass") :database-type :oracle)
At this point CMUCL starts using the processor on >90% and stays that way untill killed.
I've tried the same dialog without SLIME and it works fine. Also, I've tried with SQLite instead of Oracle and it works under SLIME.
Any ideas?
Regards, Ivan
Ivan Toshkov ivan@toshkov.org writes:
I'm using recently updated version of SLIME, CMUCL 19a, CLSQL 3 and Oracle 8.1.7, everything on linux (Red Hat Enterprise Server 3).
I do:
CL-USER> (asdf:oos 'asdf:load-op :clsql-oracle) CL-USER> (use-package :clsql-user) CL-USER> (connect '("SID" "user" "pass") :database-type :oracle)
At this point CMUCL starts using the processor on >90% and stays that way untill killed.
I've tried the same dialog without SLIME and it works fine. Also, I've tried with SQLite instead of Oracle and it works under SLIME.
The usual way to peg CMUCL at high CPU is to use threads without starting the idle process. Are you using any threads? If so try doing (setq slime-multiprocessing t) in Emacs and in ~/.swank.lisp do (setq swank:*communication-style* :spawn)
We really need a nicer way to configure this. The fly in the ointment is that we have to call (mp::startup-idle-and-top-level-loops) via the Lisp listener in *inferior-lisp* because the scary magic it does doesn't work from an RPC or init file AFAICS.
If there are no threads involved then I suggest interrupting Lisp while it's chewing CPU and having a look at the backtrace.
-Luke
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 19 August 2004 11:49, Luke Gorrie wrote:
The usual way to peg CMUCL at high CPU is to use threads without starting the idle process. Are you using any threads? If so try doing (setq slime-multiprocessing t) in Emacs and in ~/.swank.lisp do (setq swank:*communication-style* :spawn)
I hadn't started any threads, but perhaps the oracle backend does? Don't know, but this seems to help. The only problem is that CMUCL is not very resposnive, this way. It takes about a second or so to evaluate anything, even a self-eval numbers. Is there a way around this?
We really need a nicer way to configure this. The fly in the ointment is that we have to call (mp::startup-idle-and-top-level-loops) via the Lisp listener in *inferior-lisp* because the scary magic it does doesn't work from an RPC or init file AFAICS.
If there are no threads involved then I suggest interrupting Lisp while it's chewing CPU and having a look at the backtrace.
Tried C-c C-c, C-c C-g, C-g C-c and C-g C-g. Neither helped.
-Luke
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 19 August 2004 13:00, Ivan Toshkov wrote:
On Thursday 19 August 2004 11:49, Luke Gorrie wrote:
The usual way to peg CMUCL at high CPU is to use threads without starting the idle process. Are you using any threads? If so try doing (setq slime-multiprocessing t) in Emacs and in ~/.swank.lisp do (setq swank:*communication-style* :spawn)
I hadn't started any threads, but perhaps the oracle backend does? Don't know, but this seems to help. The only problem is that CMUCL is not very resposnive, this way. It takes about a second or so to evaluate anything, even a self-eval numbers. Is there a way around this?
I've forgot to alter the emacs part. Now it works fine.
Cheers, Ivan
Ivan Toshkov ivan@toshkov.org writes:
I hadn't started any threads, but perhaps the oracle backend does?
grep reveals threads-based code in CL-SQL so this seems likely.
You can use `C-c C-x t' to get a buffer listing all threads.
Don't know, but this seems to help. The only problem is that CMUCL is not very resposnive, this way. It takes about a second or so to evaluate anything, even a self-eval numbers. Is there a way around this?
Does it only become slow after you connect with CL-SQL? And if you run it outside SLIME then the toplevel remains responsive?
Generally it's easy to get "starvation" with CMUCL's threads since they aren't preemptive. But I don't understand why you would get it only under SLIME.
-Luke
-
Ivan Toshkov -
Luke Gorrie