Killing threads, and os.system()

[John Nagle]

On 1/31/2012 8:04 AM, Dennis Lee Bieber wrote:
> ({muse: who do we have to kill
> to persuade OS designers to incorporate something like the Amiga ARexx
> "rexxport" system<G>}).

    QNX, which is a real-time microkernel which looks like POSIX to
applications.  actually got interprocess communication right.  It
has to; everything in QNX is done by interprocess communication,
including all I/O.  File systems and drivers are ordinary programs.
The kernel just handles message passing, CPU dispatching, and timers.
QNX's message passing looks more like a subroutine call than an
I/O operation, and this has important implications for efficient CPU 
dispatching.

    Any QNX system call that can block is really a message pass.  Message
passes can be given a timeout, and they can be canceled from another
thread.  The "system call" then returns with an error status.  This
provides a way to keep threads from getting "stuck" in a system call.

(Unfortunately, QNX, which survived as a separate company for decades,
sold out to Harmon (car audio) a few years ago. They had no clue
what to do with an OS.  They sold it to Research In Motion, the
Blackberry company, which is in the process of tanking.)

     Python's thread model is unusually dumb.  You can't send signals
to other threads, you can't force an exception in another thread, and
I won't even get into the appalling mess around the Global Interpreter
Lock.  This has forced the use of subprocesses where, in other 
languages, you'd use threads.  Of course, you load a new copy of the
interpreter in each thread, so this bloats memory usage.

				John Nagle