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.