Re: [Sbcl-devel] RFC: exiting SBCL vs returning from a thread vs aborting a thread

[<me...@re...>]

Jianshi Huang <jia...@gm...> writes:

> 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.

What about the other threads? They should be [attempted to be] brought
down as well.

>>  When ABORT is true, SBCL exits immediately by calling _exit(2).
>>
>
> In AllegroCL, ABORT is called NO-UNWIND, which I think is more
> informative.

As always there is a tradeoff between generality and specificity. ABORT
has the advantage that if the need arises more cleanups can be made
conditional on it. NO-UNWIND provides more information about the current
state of affairs.

> 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

A superficial ouch: :NO-UNWIND makes me sad, much prefer a non-nil
default as in (UNWINDP T).