[Python-3000] python-safethread project status

[Adam Olsen]

On Tue, Apr 8, 2008 at 4:46 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Adam Olsen wrote:
>  > Killing threads at arbitrary points really is that dangerous.
>
>  I'm not talking about killing an arbitrary thread, but
>  a particular thread that I've designed with the idea of
>  killing it in mind.
>
>  And I'm not really talking about killing it, either,
>  just having a way of tapping it on the shoulder and
>  getting its attention whatever it happens to be doing.
>
>  I don't believe that's an outrageously unreasonable
>  thing to want to be able to do.
>
>  To be precise, what I have in mind is this:
>
>  1) A way of causing an exception to be raised asynchronously
>     in another thread.
>
>  2) Such exceptions would be automatically blocked in
>     a finally clause.
>
>  3) There would be a way of explicitly blocking them
>     around a section of code, e.g. using a context manager.
>
>  4) If it makes anyone feel any better, they could be
>     blocked by default until explicitly enabled by the
>     thread concerned.
>
>  5) When a thread dies, either:
>
>     a) Any locks it is holding are automatically released,
>        or
>
>     b) An exception is raised in the main thread if it dies
>        while holding any locks (since this indicates a programming
>        error, i.e. the thread failed to clean up after itself
>        when receiving an asynchronous exception).
>
>  Can anyone point to a reason it would be difficult to write
>  well-behaved threaded code in the presence of these features?

I think what bothers me is I want the restrictions to be enforced
upfront, so any violation produces a clear exception, whereas your
proposal does not diagnose them until later.  As a counter proposal,
you could either forbid acquiring locks, or have them implicitly block
the asynchronous exception.

It's also worth noting that we have very little info on how a given
operation is subdivided.  I personally think that's a good thing - if
you need it, you're doing something wrong.

I have only two use cases in mind:
1. CPU bound tasks that can't be subdivided, such as 10**10**10
2. Arbitrary code in the interactive interpreter

The latter can't be done sanely.  It's simply accepting that between a
hung interpreter and a possibly (but unlikely) corrupted user program,
we'd rather risk corrupting the user program.

-- 
Adam Olsen, aka Rhamphoryncus