Kill GIL

[Donn Cave]

In article <mailman.2531.1108389225.22381.python-list at python.org>,
 Dave Brueck <dave at pythonapocrypha.com> wrote:
> Donn Cave wrote:
[... re stackless inside-out event loop ]
> > I put that together with real OS threads once, where the I/O loop was a
> > message queue instead of select.  A message queueing multi-threaded
> > architecture can end up just as much a state transition game.  
> 
> Definitely, but for many cases it does not - having each thread represent a 
> distinct "worker" that pops some item of work off one queue, processes it, 
> and 
> puts it on another queue can really simplify things. Often this maps to 
> real-world objects quite well, additional steps can be inserted or removed 
> easily (and dynamically), and each worker can be developed, tested, and 
> debugged 
> independently.

Well, one of the things that makes the world interesting is
how many different universes we seem to be coming from, but
in mine, when I have divided an application into several
thread components, about the second time I need to send a
message from one thread to another, the sender needs something
back in return, as in T2 = from_thread_B(T1).  At this point,
our conventional procedural model breaks up along a state fault,
so to speak, like

       ...
       to_thread_B(T1)
       return

    def continue_from_T1(T1, T2):
       ...

So, yeah, now I have a model where each thread pops, processes
and pushes messages, but only because my program spent the night
in Procrustes' inn, not because it was a natural way to write
the computation.  In a procedural language, anyway - there are
interesting alternatives, in particular a functional language
called O'Haskell that models threads in a "reactive object"
construct, an odd but elegant mix of state machine and pure
functional programming, but it's kind of a research project
and I know of nothing along these lines that's really supported
today.

   Donn Cave, donn at u.washington.edu