On Mon, Apr 30, 2012 at 5:32 AM, Nikodemus Siivola
> On 30 April 2012 03:14, Jianshi Huang <jianshi.huang@...> 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
> 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
*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
黄 澗石 (Jianshi Huang)