decorators vs GIL

[G. S. Hayes]

mudd at vex.net wrote in message news:<mailman.1441.1092142125.5135.python-list at python.org>...
> state machines and processes [and inter-process
> communication/coordination]?  It sounds like you're saying the alternative
> to threads is "home brewed" threads.

No.  I'm using alternative multiprocessing/event-driven programming
methods that are much less error prone (ie easier to program and
maintain) and easier to get good performance out of than using
threads.  The core difference between threads and processes is that
threads share all their memory while processes have protected memory. 
That difference _should_ be the deciding factor in whether you use
processes or threads in an application, although as I've said
throughout this thread two major platforms (Windows{see * below} and
Java) don't give you the tools to make that possible; thankfully,
Python does on OSes where it's possible.

I'll repeat: On platforms with sane process implementations, the
deciding factor between using threads or using processes should be
whether you want all your memory (including the code) shared or not. 
Because  THAT is the fundamental difference between the two.

99% of the time, throwing out protected memory is the wrong thing to
do; it is extremely error prone, difficult to debug, and while it
often seems easy to design a multithreaded program up front it almost
always winds up being more work than using events and processes where
needed.  In many cases it'll run dramatically slower than a multiple
process implementation as well.

Note that I'm not alone in this belief; since you seem particularly
interested in the GUI side of things, you might consider reading John
Ousterhout's famous paper "Threads Considered Harmful" (he's the
author of Tcl/Tk and knows a thing or two about programming GUI apps).

> Until recently linux implemented threads as processes.

This is not true for any reasonable definition of "recently".  What
has recently changed is how the threads are shown by tools like ps and
top, and the threading library has changed from LinuxThreads to a more
efficient implementation (NPTL) that uses faster mutexes.  But the
core COE implementation hasn't changed in nearly a decade (since 1996
at least):

Linux implements arbitrary "contexts of execution" in a way similar to
Plan 9.  Traditional processes and threads are just two kinds of COE;
COEs can share various attributes.  A traditional thread is akin to a
COE that shares memory, whereas traditional processes don't.  But
other attributes (e.g. signal handlers or even the filesystem
namespace) can be private or shared.  "thread" and "processes" are
only two instances of a much more flexible object.

Various other OSes (e.g. Irix, BSD) do similar things (often using the
name "sproc" or "rfork" instead of "clone).

>  I'm really not concerned with how the threads are implemented in the 
> thread library.  I just don't want a language to prevent me from 
> accessing the thread library.

I agree, though I'd much rather use a language like Python that hides
the thread library than a language like Java that hides the much more
useful process library.

*Windows has an excellent I/O Completion Port mechanism for
event-driven programming that can build very efficient multiplexed I/O
(e.g scalable network servers); Linux's queued realtime signals were
based in part on that mechanism.