[Python-ideas] Thread exceptions and interruption

[Adam Olsen]

On 9/19/07, Guido van Rossum <guido at python.org> wrote:
> Regarding the issue of exceptions in threads, I indeed see it as a
> non-issue. It's easy enough to develop a subclass of threading.Thread
> which catches any exceptions raised by run(), and stores the exception
> as an instance variable from which it can be retrieved after join()
> succeeds.
>
> Regarding the proposal of branching the call stack, it reminds me too
> much of the problems one has when a fork()'ed child raises an
> exception which ends up being handled by an exception handler higher
> up in the parent's call stack (which has been faithfully copied into
> the child process by fork()). That has proven a major problem, leading
> to various warnings to always catch all exceptions and call os._exit()
> upon problems. I realize you're not proposing exactly that. I also
> admit I don't exactly understand how you plan to deal with the
> situation where one thread raises an exception which the spawning
> location fails to handle, while another thread is still running (but
> may raise another exception later). Is the spawning thread unwound?
> Then what's left to catch the second thread's exception? But all in
> all it gives me the heebie-jeebies.

I don't see what you're getting at.  No stack copying is done so fork
is irrelevant and the spawning threads *always* blocks until all of
its child threads have exited.

Let's try a simpler example, without the main thread (which isn't
special for exception purposes):
(Make sure to look at it with a monospace font)

           / baz
foo - bar +- baz
           \ baz

bar encapsulates several threads.  It makes no sense unravel the call
tree while a lower portion of it still exists, so it must wait.  If
there is a failure, bar will politely tell all 3 baz functions to
exit, but they probably won't listen (unless they're calling I/O).  If
necessary bar will wait forever.

foo never sees any of this.  It is completely hidden within bar.


> Finally, may I suggest that you're perhaps too much in love with the
> with-statement?

I've a preference for writing as a library, rather than with new syntax. ;)


-- 
Adam Olsen, aka Rhamphoryncus