[slime-devel] slime has broken cmucl mp

[Helmut Eller]

* 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.