Re: [Sbcl-devel] Threads, interrupts, sessions

[<me...@ho...>]

On Wednesday 09 August 2006 12:52, Nikodemus Siivola wrote:
> I believe we are all pretty much agreed that...
>
> * asynch interrupts are nasty, but essentially OK if used to just
>   execute something in the thread, and then allow it to continue on
>   its merry way?

Yes, they are much less dangerous that way. One can still do bad things 
to thread local state, streams come to mind. But that's expected and 
can be handled if you are careful enough.

> * trouble really rears its head when we unwind from an interrupt or
>   kill the thread without unwinding?

Yes.

> * all the same, the ability to unwind or forcibly kill other threads
>   is valuable during development?

Yes.

> * asynch interrupts are generally better as debugging tools then as
>   parts of application code?

Generally, yes.

> Assuming these statements are non-controversial, what about sessions?
> Do they serve any other purpose except terminal management and a way
> to (unsafely) kill a number of threads at one go?
>
> The problem with sessions, as I see it, is that they rely deeply on
> the ability asynchronously kill/unwind other threads, which is a
> false assumption.
>
> If a sensible way to deal with terminal ownership / debugger issues
> other then sessions is worked out, can we do away with them?

Absolutely, I don't think that sessions serve as terminal multiplexers 
very well. These are my thoughts on this from a year ago:

http://article.gmane.org/gmane.lisp.steel-bank.devel/5178

[Somewhat related, is the issue of WITH-TIMEOUT that should be 
deprecated and timeouts be supported directly by streams, locks, etc. I 
have to dig up what I had in mind wrt stream deadlines.]

> Cheers,
>
>   -- Nikodemus              Schemer: "Buddha is small, clean, and
> serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."