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 python
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, that
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 way,
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 thread-safe.
for example:
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 *everything*,
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 exception),
so i don't expect the thread to recover. it should just die silently.
sounds better now?
-tomer
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
