From: Jianshi H. <jia...@gm...> - 2012-01-06 06:15:37
|
On Sat, Dec 31, 2011 at 10:31 PM, Nikodemus Siivola <nik...@ra...> wrote: > > function SB-EXT:EXIT &key code abort > > Terminates the process, causing SBCL to exit with CODE. CODE > defaults to 0 when ABORT is false, and 1 when it is true. > > When ABORT is false (the default), current thread is first unwound, > *EXIT-HOOKS* are run, and standard output streams are flushed before > SBCL calls exit(2) -- at which point atexit(3) functions will run. > > When ABORT is true, SBCL exits immediately by calling _exit(2). > In AllegroCL, ABORT is called NO-UNWIND, which I think is more informative. Is there any case that I don't want to unwind but still want *EXIT-HOOKS* be called? If we want to prohibit *EXIT-HOOKS* we can setf it explicitly. Or how about this: function SB-EXT:EXIT &key code abort no-unwind no-exit-hooks and abort means :no-unwind t :no-exit-hooks t > Recursive calls to EXIT cause EXIT to behave as it ABORT was true. > Do you mean another EXIT called from the *EXIT-HOOKS*? Why not just binding *EXIT-HOOKS* to nil. Am I missing something? > RETURN-FROM-THREAD is the bit that's trivial to leave out if it is > deemed unnecessary or undesirable, but IMO it seems like a useful > thing to have. > I think the convenience it brings is worthwhile. Cheers, -- 黄 澗石 (Jianshi Huang) http://huangjs.net/ |