[Python-3000] threading, part 2

[tomer filiba]

let me bring this anew, as the the previous discussion has gone quite off
tracks.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060808/ee3aa259/attachment.htm