On Jan 4, 10:53 pm, John Nagle <na...@animats.com> wrote: > There are systems where there's support designed in for thread > abort. LISP/Scheme systems tend to support it. QNX, the real-time > OS, has well worked out thread-abort semantics at the C level. > (QNX has really good features for "not getting stuck", like the > ability to put a time limit on any system call.)
Yes, but "not getting stuck" and ending the thread execution is only one small part of the problem (and arguably the least significant). What we really want is a way to abort without harming other threads of execution, which is the hard part. QNX doesn't ipso facto make that easier. Functionality like time limits on system calls is more about latency guarantees and priority than "getting stuck" in a deadlock sense. > What you'd really like in Python is the ability for one thread > to be able to force an exception in another thread, plus a > mechanism for locking out such exceptions for critical sections. > It's not worth having, though, in a system where you can really only > run one thread at a time. Exceptions and critical sections are rather fundamentally incompatible, hence the absurd amount of gymnastics .NET goes through to attempt to make ThreadAbortException functional (and still fails rather miserably). If you had STM or 'antitry' blocks, then exceptions might be a semi-saneish way to abort a thread. Without either, I'm not entirely convinced of the utility. Only allowing the exception to be thrown from defined cancellation points is much better (ala POSIX threads), but diminishes the utility for things that are mostly grinding away in userspace. Adam -- http://mail.python.org/mailman/listinfo/python-list
