In article <[EMAIL PROTECTED]>,
Dave Brueck <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
