[Python-3000] threading, part 2
Jim Jewett
jimjjewett at gmail.com
Tue Aug 8 21:31:37 CEST 2006
On 8/8/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> my previous suggestion asked for is a means to raise exceptions in the
> context of *other* threads.
...
> * breaking the thread's state -- that's not really an issue. i'm not talking
> about *forcefully* killing the thread, without cleanup.
This has the same inherent problem as Java's Thread.stop -- that data
shared beyond the thread may be left in an inconsistent state because
the cleanup wasn't done, perhaps because a lock was held.
https://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
> so it's may seem brute to suggest a mechanism that raises exceptions
> at arbitrary points in your code-flow, but:
If you're willing to forget about native code (and you suggested that
you were), then you could just check[*] every N bytecodes, the way the
interpreters already checks to decide whether it should switch
threads. Whether the performance overhead is worthwhile is a
different question.
It might be better to just add an example thread to threading.py (or
Queue) that does its processing in a loop, and checks its own stop
variable every time through the loop.
[*] What to do in case of a raise it a bit trickier, of course --
basically, replace the next bytecode with a RAISE_VARARGS bytecode,
but that might violate some current try-except assumptions.
-jJ
More information about the Python-3000
mailing list