[imp-hackers] cl-ext:exit

[Nikodemus Siivola]

2009/7/2 Raymond Toy <toy.raymond at gmail.com>:
> I changed the list a bit late, but cl-ext:exit seems reasonable.  But
> you didn't mention exactly what you want cl-ext:exit to do.  Can you
> propose something more concrete?

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):

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

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

* at_exit interaction.

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

* OS status code.

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

* Should there be a way to tell that an exit is in progress? (Code
being run by a cleanup form or an exit-hook as part of the exit?)

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

* Which parts are optional / implementation dependent?

In my mind this would live in package CL-EXT, which not would be
provided by a library, but by implementations. Of course a portable
one would be easyish to make, but pretty much runs against the idea of
showing that implementations _can_ agree on new things...

Need to consider what is sufficient consensus for something to be put
in CL-EXT. I'm inclined to say "three implementations support the same
function with the specified API in their implementation specific
extension packages and consider that API worth semi-perpetual
freezing" is probably close enough, but that's not the only
possibility by any means.

Cheers,

 -- Nikodemus