Helmut Eller e9626484@stud3.tuwien.ac.at writes:
More on yesterday's experiments. The attached patch
Where is it? :)
One day I'll learn how to drive a mail reader.
(1) adds :debug as a valid state transition from the idle state
Perhaps a different name for the event, e.g, :async-debug, would be better. There is a certain risk that this transition hides (unrelated) bugs, if we use the same name. We might also consider to make this an out-of-band event.
You're more familiar with the protocol-level stuff than I am; I defer to your experience here.
I assume you would like the set *invoke-debugger-hook*, so that it is used in your asynchronous handlers.
Right
We could modify the swank-server and enter an infinite loop instead of using fd-handlers for request processing. This "slime-loop" (idle-loop? break-loop?) would be similar to the sldb-loop. Assignments to special variables would then be visible as long as you are in the dynamic extend of the slime-loop. Is it acceptable that all your handlers run in the dynamic extend of the this loop?
I don't think that's going to work in the context I have in mind: a long-lived server to which SLIME is connected periodically for debugging or upgrades. In a multithreaded server, all my request-answering processes are in their own threads which were started outside of a SLIME connection (perhaps at boot time) and will probably last for longer than the current SLIME session. Perhaps for HTTP it wouldn't hurt too much to tear them down and create new ones in a SLIME context, but for some more stateful protocol it'd be more pain.
A secodary but probably solvable issue is that as currently implemented the sldb-loop blocks all serve-event processing, so new requests aren't getting answered when the debugger is active. This is for the moment livable with (and saves us from implementing the lock on the debugger that's next on the hacking list) but if simply connecting slime to the process is henceforth going to freeze it, that's not so great.
Another idea is that we allow support multiple sessions with multiple tcp connections (each session a dedicated connection). A asynchronous handler could then initiate a new session.
Not so wild about multiple TCP connections. My ultimate goal is to be able to slime across a network, which may require SSH tunnelling or other interesting configurations,
make this a (with-debugging-hooked ...) macro, but I think thatUntil now we worked around this problem and used functions like call-with-debugging-hooked. The function is then defined later. Perhaps we should split the files again, so that the build order would be like: swank-early, swank-sbcl-early, swank, swank-sbcl. The
Yeah, I saw that, but the lambdas on lambdas were starting to make me dizzy, so I went with the simple solution for the time being. I know that refactoring the build is being talked about anyway: perhaps this can be addressed in that context
-dan