[Python-3000] improved threading in py3k

Josiah Carlson jcarlson at uci.edu
Fri Aug 4 23:02:28 CEST 2006

"tomer filiba" <tomerfiliba at gmail.com> wrote:
> > I'm curious as to what I have done to deserve the rudeness of your reply.
> well, i'm kinda pissed off by rockets flying over my house, svn giving me a
> hard life, and what not. but what you have done was dismissing my post on
> shaky grounds.

Ick.  I can understand how you are frustrated.

> > According to recent unrelated research with regards to the Win32 API,
> > most thread killing methods (if not all?) leaves the thread state broken
> > in such a way that the only way to fix it is to close down the process.
> > Then again, I could be misremembering, the Win32 API is huge.
> that may be so, but my suggestion wasn't *killing* the thread directly -
> i'm sure one can use win32api to forcefully kill threads.
> my idea, which is loosely based on dotNET (perhaps also applicable in java),
> was raising a ThreadExit exception in the context of the given thread.
> that way, the exception propagates up normally, and will eventually cause
> the thread's main function to exit silently, unless caught (just as it works
> today).
> the issue here is raising the exception in *another* thread (externally);
> this could only be done from a builtin-function (AFAIK); the rest of the
> mechanisms are already in place.

One of the use-cases you specified was that C calls could perhaps be
aborted (an artificial timeout).

Does there exist a mechanism that is able to abort the execution of C
code from another C thread without killing the process?  If so, then
given that the C could be aborted at literally any point of execution,
how could any cleanup be done?

 - Josiah

More information about the Python-3000 mailing list