[imp-hackers] cl-ext:exit

[Sam Steingold]

On Fri, Jul 10, 2009 at 11:19 AM, Juan Jose
Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
> On Fri, Jul 10, 2009 at 4:44 PM, Sam Steingold<sds at gnu.org> wrote:
>>> * What is the behaviour wrt. multiple threads if they exist? Should
>>> EXIT always exit all threads? (I'm inclined to say yes.)
>>
>> of course.
>
> Not so evident. I would provide this function ALSO with the
> possibility of exiting only the current thread..

if you want "exitable threads", just wrap the thread functions in a catch:

(create-thread (lambda () (catch 'exit-thread (my-func))))

and then
(defun exit-thread () (throw 'exit-thread))

>>> * Behavious wrt. nested exits: what should happen if EXIT is caled
>>> again while unwinding or running exit-hooks.
>>
>> treat it as abort()
>
> I am not sure this makes sense: ignore unless the user really uses :abort t

I think calling exit from exit-hooks should be taken as an indicator
of a major disaster.

>>> In my mind this would live in package CL-EXT
>>
>> why not just EXT?
>
> Because prefixed names are interesting in order to let the user with
> greater freedom.

I cannot parse this sentence, sorry.

however, there are no hierarchical packages in CL
(which is a pity, maybe we need a clfri for that),
so CL-EXT is just a single name, not a "pathname" /CL/EXT
and thus it carries no useful information over a plain EXT.
I guess, you are just following the analogy of CL-USER...

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