[Python-3000] threading, part 2

[Marcin 'Qrczak' Kowalczyk]

Josiah Carlson <jcarlson at uci.edu> writes:

>> It's not realistic to expect sys.setcheckinterval be implementable on
>> other runtimes.
>
> The 'raise an exception in an alternate thread' functionality is a
> CPython specific functionality.  If you believe that it could be
> implemented in all other runtimes, then you missed the discussion that
> stated that it would be impossible to implement in Jython.

Indeed both are hard to implement on some runtimes.

I believe there are runtimes where asynchronous exceptions are
practical while blocking context switching is not (e.g. POSIX threads
combined with Unix signals and C++ exceptions).

In any case, blocking switching the context to any other thread is an
overkill. It's hard to say how sys.setcheckinterval should behave on
truly parallel runtimes, while the semantics of blockable asynchronous
exceptions doesn't depend on threads being dispatched sequentially.

>> Also, it doesn't provide a way to unblock asynchronous exceptions until
>> a particular blocking operation completes.
>
> I thought the point of this 'block asynchronous exceptions' business
> was to block asynchronous exceptions during a particular bit of code.
> Now you are saying that there needs to be a method of bypassing such
> blocking from other threads?

No, I'm talking about specifying the blocking behavior by the thread
to be interrupted. It makes sense to wait for e.g. accept() such that
asynchronous exceptions are processed during the wait, but that they
are atomically blocked as soon as a connection is accepted.

Unfortunately it's yet another obstacle to some runtimes.

Yet another issue is asynchronous "signals" which don't necessarily
throw an exception but cause the computation to react and possibly
continue (e.g. suspend a thread until it's resumed).

> Yes, it can be.  You can add a lock to each thread (each thread gets its
> own lock).  When a thread doesn't want to be interrupted, it .acquire()s
> its lock.  When it is OK to interrupt it, it .release()s its lock.  When
> you want to kill a thread, .acquire() its lock, and kill it.

This works almost well. The thread sending an exception is unnecessarily
blocked; this could be solved by starting another thread to send an
exception. And it doesn't support the mentioned unblocking only while
waiting.

The problem is that there is no universally recognized convention:
I can't expect third-party libraries to protect their sensitive
regions by my mutex. Without an agreed convention they can't even
if they want to.

My design includes implicit blocking of asynchronous exception by
certain language constructs, e.g. by taking *any* mutex. Most cases
of taking a mutex also want to block asynchronous signals.

I'm surprised that various runtimes that I would expect to be well
designed provide mostly either unsafe or too restricted means of
asynchronous interruption.
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
http://www.interact-sw.co.uk/iangblog/2004/11/12/cancellation

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