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

tomer filiba tomerfiliba at gmail.com
Fri Aug 4 20:55:55 CEST 2006

[...] 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 >>> >>> killthese = {} >>> >>> def killthread(thread): ... killthese[thread] = None ... >>> def trace(*args): ... del args ... if threading.currentThread() in killthese: ... #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) >>> killthese {<Thread(Thread-1, started)>: None} >>> x in killthese 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

More information about the Python-3000 mailing list