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