[Python-3000] threading, part 2
Josiah Carlson
jcarlson at uci.edu
Fri Aug 11 20:18:56 CEST 2006
"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote:
>
> Josiah Carlson <jcarlson at uci.edu> writes:
>
> > There is already a way of making Python source execution atomic with
> > respect to other Python code [1].
>
> 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. As such,
because both are CPython specific features, I don't see a problem with
using both if you are going to be using one of them.
> 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?
> > If you don't want random exceptions being raised in your threads, then
> > don't use this method that is capable of raising exceptions somewhat
> > randomly.
>
> It's like saying "if you don't want integer addition overflow, then
> don't do addition".
No. Integer addition is a defined feature of the language. Raising
exceptions in an alternate thread is a generally unsupported feature
available to CPython, very likely not implementable in most other
runtimes.
It has previously been available via ctypes, but its previous non-use is
a function of its lack of documentation, lack of cytpes shipping with
base Python, etc.
> I do want asynchronous exceptions, but not anywhere, only in selected
> regions (or excluding selected regions). This can be designed well.
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.
In effect, the above would be what is necessary to give you what you
want. It can easily be defined as a set of 3 functions, whose
implementation should be left out of the standard library. Including it
in the standard library offers the illusion of support (in the 'this
language feature is supported' sense) for raising an exception in an
alternate thread, which is not the case (it is available, but not
supported).
- Josiah
More information about the Python-3000
mailing list