Bulent Murtezaoglu <bm@...> writes:
> -- The manual is accurate in that save-lisp-and-die does not work if
> multiple threads are running. It dies alright, but it also creates a
> zero length file while doing so. Is there a good reason other than
> lack of developer interest/time for not having it detect if more than
> one thread is running and refuse to do anything?
More like no-one thought of it before. ,-)
Seems simple enough to do, and a nice idea. While save-lisp-and-die
isn't ment for saving state, some people do use it for that -- so
signaling an error instead of losing data is a decent thing to do.
> While this does work OK for dumping hello world and such from an sbcl
> running under slime, I don't understand what forking an sbcl with
> multiple running threads does and in what way the image might be
> broken.
I belive fork() duplicates only the thread it is being called from,
which may create problems in the child SBCL, as it knows about the
other threads that were running, but are now missing -- except that
the thread-id provided by the OS points to a running thread in another
process.
But possibly this situation is sufficiently similar to having dead
threads that the GC will handle it sanely?
fork() should be fine even in multithreaded environment if you are
going to live in foreign code from that point on -- I'd only expect
trouble at next GC (or PURIFY).
This whole mess is probably fixable by creating appropriate
pthread_atfork() handlers for each thread started by SBCL, or
making the GC deal with the pre-fork leftovers.
> I figured the manual's suggestion was serious and tried it. If this
> is indeed kosher perhaps a better version of something like the
> above could enter the manual as an example?
Aside from the issue that threads are liable to be a problem with
fork() too, I don't see why not.
> (Details for getting the child process to output into the slime repl
> buffer rather than the inferior lisp one probably doesn't belong in
> the sbcl manual, but if it can be done from the swank/sbcl-side, I'd
> be happy to find out how).
I would expect judicious use of INSPECT to point to way.
(*STANDARD-OUTPUT* in child vs. *STANDARD-OUTPUT* in parent.)
> -- Would it be a good idea to add something more concrete to the
> explanation for the :executable key for sb-ext:save-lisp-and-die? It
> could say something like:
>
> ":executable If true, arrange to combine the sbcl runtime and the core
> image to create a standalone executable. If false (the default), the
> core image will not be executable on its own. If a standalone executable
> is being created sb-ext:quit should be called before exiting lisp
> entirely."
>
> The last sentence could probably also be added to the explanation for
> :toplevel. It could also be that I'm missing something and there are
> other ways of exiting normally. If so, what are they? What should I
> tell people, if asked?
Calling exit() in foreign code, for example.
On the other paw, I'd personally prefer to automatically QUIT with
return code of 0 if the toplevel function returns.
> -- Does it make sense for there to be any command line processing for
> sbcl's own switches in a standalone executable? I started thinking
> about this issue when I realized I needed to call my test executable
> with --noinform to stop the start-up banner from getting printed.
> Regardless of what the right thing turns out to be for the switch
> issue, the banner issue remains. There does not seem to be any way
> (short of editing runtime.c and rebuilding) to turn off the printing
> of the banner in the dumped executable w/o using that command-line
> switch. Perhaps something as simple as not calling print_banner() if
> the exectuable is standalone would work OK?
This has been talked about.
My personal favorite is to move as --noinform processing out of the
runtime onto lisp-land, so that the inform-messages could be
customized (including motd-like things) or suppressed entirely by
saving a core with the appropriate hooks.
I also suspect that using --sbcl-version and --sbcl-core, instead of
--version and --core as commandline arguments for executable cores
would be a good idea.
Surely
$ frobniz --version
should return the version of frobniz, not the SBCL it was built on!
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
|