[Python-3000] improved threading in py3k (original) (raw)

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?

More information about the Python-3000 mailing list