[slime-devel] Asynchronous debugging

[Daniel Barlow]

Helmut Eller <e9626484 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: application/octet-stream
Size: 3737 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20031125/bd4ad33b/attachment.obj>
-------------- next part --------------

>> (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 that
>
> Until 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

-- 

   http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20031125/bd4ad33b/attachment.sig>