[Python-3000] improved threading in py3k

[tomer filiba]

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

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

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.

- - - -

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":

>>> import sys
>>>
>>> try:
...     sys.exit()
... except:
...     print "fooled you"
...
fooled you
>>>

if my library raises SystemExit, but the user is not aware of that, he/she
can block it [un]intentionally, causing undefined behavior in my library.
os.exit() would really just perform cleanup and exit (not by the means
of exceptions)... just like os._exit(), but not as crude.


-tomer

On 8/4/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "tomer filiba" <tomerfiliba at gmail.com> wrote:
> > python's threading model seems too weak imo. i'm not talking about
> > the GIL and the fact threads run one at a time -- i'm talking about the
> > incompleteness of the API of thread module.
>
> I could have sworn that it could be implemented as a debugging trace
> function [1], but my tests [2] seem to imply that non-mainthread code
> doesn't actually have the trace function called.
>
>  - Josiah
>
> [1]
>
> >>> import sys
> >>> import threading
> >>>
> >>> kill_these = {}
> >>>
> >>> def killthread(thread):
> ...     kill_these[thread] = None
> ...
> >>> def trace(*args):
> ...     del args
> ...     if threading.currentThread() in kill_these:
> ...         #pick some exception unlikely/impossible to catch
> ...         raise MemoryError
> ...     return trace
> ...
> >>> sys.settrace(trace)
> >>> def waster():
> ...     while 1:
> ...             a = 1
> ...             b = 2
> ...             c = 3
> ...
> >>> x = threading.Thread(target=waster)
> >>> x.start()
> >>> killthread(x)
> >>> kill_these
> {<Thread(Thread-1, started)>: None}
> >>> x in kill_these
> True
> >>> x in threading.enumerate()
> True
> >>> threading.enumerate()
> [<Thread(Thread-1, started)>, <_MainThread(MainThread, started)>]
> >>>
>
>
> [2]
> >>> import threading
> >>> import sys
> >>> seen = {}
> >>> def trace(*args):
> ...     x = threading.currentThread()
> ...     if x not in seen:
> ...             print x
> ...     seen[x] = None
> ...     return trace
> ...
> >>> sys.settrace(trace)
> >>> def waster():
> <_MainThread(MainThread, started)>
> ...     while 1:
> ...             a = 1
> ...             b = 2
> ...             c = 3
> ...
> >>> x = threading.Thread(target=waster)
> >>> x.start()
> >>>
>
> This is in Python 2.4.3 on Windows.
>
> > - - - -
> >
> > (*) about os._exit -- how about introducing os.exit, which would serve
> > as the "nicer" version of os._exit? os.exit would kill the process in
> > the same way SystemExit kills it (performing cleanups and all).
> > in fact, the interpreter would just call os.exit() when catching SystemExit.
>
> Already exists as sys.exit()
>
>  - Josiah
>
>