-------- Original Message --------
Subject: Re: [Sbcl-help] single file exe stuff
Date: Mon, 26 Jun 2006 13:15:56 +0300
From: Nikodemus Siivola <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Bulent Murtezaoglu <[EMAIL PROTECTED]> 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."
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sbcl-help mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sbcl-help
--
Emre S.
_______________________________________________
cs-lisp mailing list
[email protected]
http://church.cs.bilgi.edu.tr/lcg
http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
