[Python-3000] threading, part 2

[Marcin 'Qrczak' Kowalczyk]

Josiah Carlson <jcarlson at uci.edu> writes:

> Threading is already difficult enough to do 'right' (see the dozens
> of threads discussing why this is really the case), and designing
> software that can survive the raising of an exception at any point
> makes threading even more difficult.

That's why I'm proposing to provide ways to limit those "any points".

> I believe that you are attempting to design an interface to make
> this particular feature foolproof.

No, I'm merely attempting to make it usable.

> I think that such is a mistake; killing a thread should be frought
> with gotchas and should be documented as "may crash the runtime".

You are proposing to make it unusable?

> Offering users anything more is tantamount to encouraging its use,
> which is counter to the reasons why it is not available via a
> standard threading.function call: because it shouldn't be used at
> all, except by people who know what the heck they are doing.

Indeed, you are proposing to make it unusable.

> I believe that if a user cannot design and implement their own
> system to handle when a thread can be killed or not to their own
> satisfaction, then they have no business killing threads.

I have already implemented it. In my own language, where I have
full control over the runtime.

Some Haskell people made the first design a few years ago,
and implemented it in Glasgow Haskell Compiler.
http://citeseer.ist.psu.edu/415348.html

Some people saw that it was good, that the existing handling of
KeyboardInterrupt in Python is unsafe, and they adapted the design
for Python (without actually implementeing it as far as I know).
http://www.cs.williams.edu/~freund/papers/02-lwl2.ps

I built on their experience, extended the design, and implemented it
in my language Kogut, so I can play with it and see how it works in
practice.
http://www.cs.ioc.ee/tfp-icfp-gpce05/tfp-proc/06num.pdf

I'm quite confident that something like this is the right design,
even if some details could be changed.

Now it would be nice if Python had usable asynchronous exceptions too.

If we are not brave enough, we can implement at least an equivalent
of POSIX thread cancellation. It would be better than nothing, though
not as useful, because the default mode allows interruption only at
certain blocking primitives. In this scenario Unix signals need a
different policy so a pure computation not performing I/O nor thread
synchronization can be interrupted; Unix signals usually cause the
whole process to abort so data integrity was less of a concern.

A language with GC and exceptions can do better, with a unified policy
for thread cancellation and Unix signals and other asynchronous events.
It can be done such that well-written libraries are safely interruptible
even if exceptions may occur almost anywhere. Protection should be
built into certain operations (e.g. try...finally extended with an
"initially" clause, or taking a mutex), so that there is less work
needed to make code safe to be interrupted; then quite often it's
already safe.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/