* Madhu [2008-10-31 02:59+0100] writes:
|> This hangs until the slime connection exits. | | It doesn't hang in the default configuration.
The scenario I outlined above WAS the default configuration. Repeating the test without a .swank.lisp and calling CMUCL with lisp -noinit
- SWANK::*COMMUNICATION-STYLE* => :SIGIO
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.
| 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.
| 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.
| It doesn't hang, even with active debugger, with | (eq *communication-style* :sigio) if multiprocessing is | initialized properly and the idle process runs. E.g. if you start the | swank server with: | | (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.
|> This is a serious problem, and exposes many issues with SLIME's design. | | Which issues?
I'm having a hard time getting you to even admit there is a problem. I suspect you are either extremely short sighted or are blind to defects.
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?
Helmut.