"tomer filiba" <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
