[Python-3000] improved threading in py3k

[tomer filiba]

> 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.

if all you meant was adding this support for the 2.x branch as a *workaround*,
i truly apologize.

> 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.

- - -

sorry for bursting out.


-tomer

On 8/4/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "tomer filiba" <tomerfiliba at gmail.com> wrote:
> >
> > > [...] it could be implemented as a debugging trace function
> >
> > even if it could be, *why*? you can't really suggest that from now on,
> > every multithreaded app must run in trace mode, right? it's a performance
> > penalty for no good reason -- it's a question of API.
>
> You can remove the performance penalty by resetting the trace function
> to None.
>
>
> > just as the API lets you *create* threads, it should allow you to *kill* them,
> > once you decide so. your code shouldn't rely on the "cooperativeness" of
> > other functions (i.e., the thread does blocking IO using some external
> > library, but you wish to stop it after some timeout, etc.).
>
> 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.
>
>
> > all i was talking about was adding a new function to the thread module,
> > as well as a new builtin exception to completement it. it's no such a big
> > change that you should work extra hours in inventing creative workarounds
> > for.
>
> It took me 5 minutes to generate that possible solution and a test for
> it.  I wasn't saying that the functionality was generally undesireable,
> just that I believed it should be possible in pure Python today (rather
> than waiting for Py3k as is the implication by your posting in the Py3k
> mailing list), and showing why it couldn't be done today.  It also
> brings up the implied question as to whether non-mainthreads should
> actually execute trace functions.
>
>
> > you said:
> > > Already exists as sys.exit()
> >
> > but i said:
> > >> it would also allow you to ensure the interpreter is killed, as SystemExit
> > >> can be caught by external code against your will.
> >
> > please take the time to read my post before you reply.
> > here is what i mean by "against your will":
>
> I wasn't aware that sys.exit() raised SystemExit, as I tend to not use
> bare excepts or sys.exit() in my code (I prefer os._exit(), because when
> I want to quit, cleanup is the least of my worries).  You could have
> said "sys.exit() raises SystemExit" and I would have understood my
> mistake.
>
>
> I'm curious as to what I have done to deserve the rudeness of your reply.
>  - Josiah
>
>