[slime-devel] [RfC] Per event bindings

[Tobias C. Rittweiler]

Hi,

I recently introduced Swank-Compilation-Units; within one such units
the compiler notes of several compilation requests are accumulated.

These units were introduced to implement C-c C-k in Xrefs buffers where
several toplevel forms should be recompiled at once (the reason we don't
do it with one request is the preservation of source-locations.)

The current implementation works perfectly fine with threads. But
there's a use case that will break for the serve-event communication
style:

Let's say you have some form which will activate some application's
event loop, and you use C-c C-c to "evaluate" the form. This C-c C-c
will bind *SWANK-COMPILATION-UNIT*. All consequent C-c C-c's will be
executed in a dynamic environment where *SWANK-COMPILATION-UNIT* is
still bound to that the unit of the application-event-loop evaluation.

This means that the compilation of all consequent C-c C-c's will be
accumulated, which means they won't be displayed at all (as long as the
event loop is running.)

The reason behind this behaviour is that I do

  (defvar *swank-compilation-unit* nil)

  (defmacro with-swank-compilation-unit (...)
   ...
   `(let ((*swank-compilation-unit* (or *swank-compilation-unit*
                                        (make-swank-compilation-unit))))
      ...))

which works perfectly reasonable for threads, but not for SERVE-EVENT,
as that will interrupt, and execute new code within the dynamic contour
of the interrupted code.

A solution to this is to introduce per event bindings which are
implemented differently depending on the communication-style used (for
:spawn, thread-local bindings can be used; for :fd-handler, we'd need
some mapping from some request-id to the value.)

Opinions?

  -T.

PS: If the form starting the application's event loop is started by
using C-M-x rather than C-c C-c this problem doesn't occur, as C-M-x
doesn't involve Swank-Compilation-Units. It could be argued that C-M-x
is the right keybinding to evaluate the form in the first place.

So there's the question if the abovely sketched solution is worthwhile
at all. Of course, we may be bitten by this in future in some form which
manifests itself in a much more obscure way than the bug described
above. This is a kinda handwaving argument, but I wanted to raise the
issue anyway.