Paul said:
It looks useful, but as far as I can tell, it's just another IPC
thingie that works through sockets, sort of like pyro without the
remote objects. I don't see how it's related to Erlang-like
concurrency (which means ultralightweight coroutines, not heavyweight
Unix or Windows processes). I think Python concurrency schemes get
interesting when they at least share memory (like POSH). Otherwise I
think of them more as "distributed" than "concurrent".
What is revolutionary about Erlang's concurrency model isn't exactly
its light weight threads (Python already has a frame work that
implements something similar) but the fact that in Erlang each thread
behaves like a process and each thread communicates with each other via
message passing. In Erlang, threads do not share state information. So
all the limitations associated with concurrent programming in other
mainstream languages are absent in Erlang. Because threads behave like
processes and do not share state, Erlang allows you to create thousands
of threads easily without the drawbacks of thread locks. Each thread or
process manages its own state. Erlang then provides a protocol to allow
each thread to communicate with each other.
You can mimic this concept with a light weight event based IPC like
D-Bus. D-Bus supports message passing and signals. It also provides you
with an easy protocol that allows processes to talk to each other. You
are right when you say that D-Bus uses heavy processes while Erlang
uses light ones. But the robustness and scalability of Erlang's
concurrency model stems from the fact that Erlang's threads are not
really threads, but light weight processes that do not share state
information. In brief, Erlang's concurrency model is basically IPC
programming with light-weight processes. This is what I say you can
mimic with D-Bus albeit, unfortunately, with heavy-weight processes.
