[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