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

[Jianshi H. <jia...@gm...>]

On Mon, Apr 30, 2012 at 5:32 AM, Nikodemus Siivola
<nik...@ra...> wrote:
> On 30 April 2012 03:14, Jianshi Huang <jia...@gm...> wrote:
>> Some feedback for further discussion:
>>
>> *exit-hooks* are invoked before calling %exit-other-threads, which
>> seems controversial to me. It means I can't use it for to free
>> resources or to guarantee all buffers are flushed since other threads
>> might still operating on them.
>
> The reason *EXIT-HOOKS* are called first now is threefold:
>
> (1) make it possible to use them to guarantee an orderly shut-down,
> which for me includes non-asynch termination of other threads.
>
> (2) since it is possible that we cannot cleanly terminate a thread
> (eg. because it's stuck inside a WITHOUT-INTERRUPTS.), there is now
> way to guarantee that we will reach a state where all threads are
> running before *EXIT-HOOKS* are called.
>

Ah, I see. Good points. But I think orderly shutdown cannot be done
properly if it's not called from the main thread. Am I missing
anything? What would you suggest it should be done?

> (3) calling them early means that it's sane (well, almost) to still
> spawn new threads from exit hooks. If we did that after thread
> termination, we could not allow it and call the shutdown orderly.
> While I don't expect exit hooks spawning threads to be a regular
> occurrence, I can still image it happening by both design and harmless
> accident.
>
> Still, your point and use-case are both perfectly valid. Maybe we need
> a second series of exit hooks as well. Name suggestions?
>
>  *AFTER-EXIT-HOOKS* ?
>
>  *FINAL-HOOKS* ?
>
> Or maybe have *EXIT-HOOKS* act as you suggest, and add
>
>  *BEFORE-EXIT-HOOKS* ?
>
> which could even be called before from the current thread. I think I
> like this option the best -- if there's a hook which is called after
> unwinding everything, it doesn't matter if the initial hook is called
> before.
>
> Thoughts?
>

*exit- and *final-, *before- and *after- both seem good to me.

>> It would be nicer if we have *thread-exit-hooks* for each thread.
>
> Can you clarify this a bit?
>
> As a thread-local binding? Can do that, but don't quite see the point
> -- how would it be different from sticking an UNWIND-PROTECT clause to
> do the same?
>
> Or do you mean as a global variable, called per thread? I guess that
> makes sense, but don't see an immediate application.
>

Yes, a global binding but also re-bound per thread. Unwind-protect is
ok, but having bindings means I can inherit same exit functions in new
threads (just rebind it, or use global binding). For convenience and
also the API seems more complete (process-scope hooks and thread-scope
hooks :)


Cheers,
-- 
黄　澗石 (Jianshi Huang)
http://huangjs.net/