[Python-3000] threading, part 2
tomerfiliba at gmail.com
Tue Aug 8 20:22:24 CEST 2006
let me bring this anew, as the the previous discussion has gone quite off
i know there are many theories/paradigms concerning parallel execution,
some require language level constructs, other being external, and let's not
ever start talking about the GIL.
(on a side note, if i may add my opinion on the subject matter, stackless
has the best approach to concurrency -- don't lock, yield!)
my previous suggestion asked for is a means to raise exceptions in the
context of *other* threads. all it calls for is for a new builtin function,
would raise a given exception at the context of a given thread.
there are some points to address:
* native calls -- well, calling builtin functions can't be interrupted that
and it is problematic, but not directly related to this proposal. that's a
problem of machine code.
* breaking the thread's state -- that's not really an issue. i'm not talking
about *forcefully* killing the thread, without cleanup.
after all, exceptions can occur anywhere in the code, and at any time...
you code should always be aware of that, with no regard to being
def f(a, b):
return a + b
an innocent function, but now suppose i pass two huge strings... bad input
can cause MemoryError, although unlikely. you can't take care of
you must learn to live with the occasional unexpected exception.
so it's may seem brute to suggest a mechanism that raises exceptions
at arbitrary points in your code-flow, but:
* cleanup will be performed (objects will be reclaimed)
* you can handle it anywhere in the call chain (just as any other exception)
* most of the time, i'd use that to *kill* threads (the ThreadExit
so i don't expect the thread to recover. it should just die silently.
sounds better now?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000