[slime-devel] unhooking from slime before saving sbcl core?

[Helmut Eller]

* Michael Hannemann [2009-03-02 04:19+0100] writes:

> Tobias C. Rittweiler wrote:
>>Michael Hannemann <mrh3 at pobox.com> writes:
>>
>>>  When I write a core image out from SBCL which I'm talking to via
>>>  SLIME, then try to load it from the command line without SLIME, I get
>>>  a long stream of warning messages.  This happens immediately on
>>>  startup.  I've deleted my .sbclrc file so user init is not to blame.
>>>  (Also, when I start up SBCL from the shell, this doesn't happen.)
>>
>>It is not a good idea trying to invoke SB-EXT:SAVE-LISP-AND-DIE while
>>Slime is connected to a running SWANK server.
>>
>>Forking first, and then invoking it, is a somewhat better idea, although
>>I'm not certain (and not knowledgeable enough) about how good it really
>>is. There's a SWANK-BACKEND:SAVE-IMAGE function which, on SBCL, goes the
>>fork route but does not seem to work at all right now.
>
>
> I actually am forking first, but I didn't want to complicate the 
> discussion unnecessarily.  It took me a while to determine it was 
> possible, since apart from an offhand reference in the SBCL manual, 
> there was no documentation anywhere for SBCL forking itself, but I 
> stumbled across the sb-posix contributed module and all was well.
>
> So:  How do I turn SWANK off in a child lisp which is about to save-and-die?

Forking is tricky due the inherited file-descriptors and it's also not
well specified whether threads are cloned or not.

In theory you can call 
(swank::close-connection (swank::default-connection) nil nil) 
to clean things up, but the whole shutdown mechanism doesn't work all
that well with threads.

[During shutdown we just want to kill our threads which can generate
certain errors.  Handling those errors outside of the thread in which
the error occurred is rather difficult. Or at least I've never seen a way
to do that cleanly.  This becomes even more complicated after fork.]

If you use global i/o redirection then you should also call
swank::revert-global-io-redirection somewhere.

> Also: Is there a good way of detecting that a SWANK server is running 
> in the first place, other than seeing if (find-package :swank) 
> returns something?

Testing swank::*connections* and swank::*listener-sockets* should work.
Both should be nil when everything is closed.

Helmut.