On Lunes 02 Marzo 2009, Helmut Eller wrote:
- Michael Hannemann [2009-03-02 04:19+0100] writes:
Tobias C. Rittweiler wrote:
Michael Hannemann mrh3@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.
SBCL's thread implementation is based on pthreads, ergo fork() does not clone threads. From the fork() manpage on my linux x86 box:
* The child process is created with a single thread — the one that called fork(). The entire virtual address space of the parent is replicated in the child, including the states of mutexes, condition variables, and other pthreads objects; the use of pthread_atfork(3) may be helpful for dealing with problems that this can cause.
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.
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel