[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