* Helmut Eller m24p2tqh6l.fsf@common-lisp.net : Wrote on Fri, 31 Oct 2008 09:53:22 +0100:
| If you start swank with swank::setup-server instead of | swank:create-server your are using a non-default configuration. Your | code passes nil as the communication-style argument to | swank::setup-server.
You are right, I was incorrect in claiming the outlined scenario used the default sigio communication style.
|> | More precisely, it doesn't hang if I run SLIME with |> | (eq *communication-style* :sigio). |> | It hangs, with the default config, if the SLIME debugger is active. |> |> The scenrario I outlined abiove which illustrates the hanging did not |> have a debugger hanging. | | That scenario is using the "read and process requests sequentially" | communication style.
Right.
|> | It doesn't hang, even with active debugger, if |> | (eq *communication-style* :spawn). |> |> COMMUNICATION STYLE of SPAWN and SIGIO interfere in various non-trivial |> ways with the behaviour of the application especially if it is a |> multiprocessing webserver. | | How does SPAWN interfere with a multiprocessing webserver? If you | want to use multiprocessing, it would seem natural to use that style.
I have not used SPAWN with CMUCL MP recently. The sequential processing of slime requests (having only one outstanding slime request at a time) proved to be most robust (from the point of view of the application).
|> | (swank::initialize-multiprocessing (lambda () (swank:create-server))) |> |> No, this is a hack in your personal setup. This precludes various other |> ways in which CMUCL can be used, introduces some problems in other |> scenarios. |> |> You cannot impose your personal configuration on every application. The |> point I'm making here is slime used to work with a range of application |> configurations. | | If you want to use CMUCL's multiprocessing you should start the idle | process somehow.
There are outstanding "bugs" in stock CMUCL which make this unreliable and hose the MP system unless started at the REPL by the Initial process. No, it is not clear to me why there are bugs, and how to go about fixing them. In some other cases the "determinism" gains from not starting an idle process is desirable.
| Is it to much to ask to spell out "the many issues with SLIME's design"? | You claimed that "[SLIME] blocks all other processes from handling FD | events". This is just not true, because SLIME calls SYS:SERVE-EVENTS. | That CMUCL's SERVE-EVENTS only calls the thread scheduler after 1 second | idleness isn't my fault. Or are you saying that SLIME shouldn't call | SERVE-EVENTS?
No, on all three points. However this is less serious a problem than I inititally imagined. Thanks for the suggestions -- Madhu