[imp-hackers] cl-ext:exit

[Sam Steingold]

On Fri, Jul 10, 2009 at 6:08 AM, Nikodemus
Siivola<nikodemus at random-state.net> wrote:
> I still intend to do a survey on implementations, but here's my mental
> list of things that need to be taken into account (at least partially
> already discussed in this thread):

these are just my opinions.

> * What is the behaviour wrt. multiple threads if they exist? Should
> EXIT always exit all threads? (I'm inclined to say yes.)

of course.

> * Exit-hooks. I think errors/serious conditions should be dealt with
> somehow, but I'm not terribly religious about that.

all continuable errors should be appeased (turned into warnings).
all others should be ignored.

> * Should support exit without unwinding, should consider how this
> related to exit-hooks and at_exit.

(exit status :abort t) should exit immediately without any unwinding
by calling abort()

> * Behavious wrt. nested exits: what should happen if EXIT is caled
> again while unwinding or running exit-hooks.

treat it as abort()

> * Should there be a way to tell that an exit is in progress? (Code
> being run by a cleanup form

if cleanup forms cannot know that the ABORT restart is in progress,
why do they need to know that exit is in progress?

> or an exit-hook as part of the exit?)

if it matters to you, you can always do
(push (lambda () (my-cleanup t)) *exit-hook*)
(defun my-cleanup (exitingp) ...)

> * Order of exit-hooks and unwinding: which is done first?

unwinding first.

> In my mind this would live in package CL-EXT

why not just EXT?

-- 
Sam Steingold <http://sds.podval.org>