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

[Gábor Melis]

On Lunes 02 Marzo 2009, Helmut Eller wrote:
> * 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.

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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/slime-devel