Re: [Sbcl-devel] Killing runaway threads

[<fa...@gm...>]

There are good reasons why most languages don't allow to kill random thread=
s:
because you cannot in general ensure that the thread isn't transiently brea=
king
some application-critical invariant (within some exclusion mechanism).
The "solution" of Java is to deprecate and remove the interface to kill thr=
eads.
If you want to provide such an interface, you should also provide a
way for the programmer
to override a per-thread mechanism for thread cleanup
(i.e. cleaning state and releasing locks).
Note that sometimes it isn't possible the clean the state before
releasing the locks...
but sometimes, you're killing the other clients of the lock, too
so it doesn't always matter that much.

[ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu=
nes.org ]
You cannot teach a man anything; you can only help him find it for himself.
        -- Galileo Galilei


On 19/06/06, Nikodemus Siivola <nik...@ra...> wrote:
> G=E1bor Melis <me...@ho...> writes:
>
> > The patch looks reasonable to me. About the interface, instead of
> > THREAD-EXIT (which should be EXIT-THREAD anyway), you could undeprecate
> > DESTROY-THREAD and make it interrupt the target thread with (lambda ()
> > (handle-thread-exit thread)).
>
> That seems reasonable.