[zeromq-dev] Erlang style messaging

Pieter Hintjens ph at imatix.com
Thu Aug 28 17:25:55 CEST 2014


You may enjoy the CZMQ zactor model, which is somewhat inspired by
Erlang's view of things.

On Thu, Aug 28, 2014 at 4:58 PM, Steve Murphy <murf at parsetree.com> wrote:
> Pieter--
>
> Last year, I read the book, Programming Erlang, by Joe Armstrong, and I was
> fascinated by the ideology behind the general thread-per-object approach,
> where
> each "object" is managed by its own thread, via message passing.
>
> Erlang has a really "involved" message passing scheme, involving pattern
> matching, a "mailbox", recieve timer, a "save queue". Needless to say, all
> this makes a very powerful way of prioritizing messages, so a busy object
> manager can pull high-priority requests from the mailbox and act on them
> immediately, saving lower priority requests for later.
>
> I see in a paper at http://zeromq.org/blog:multithreading-magic, the same
> sort of admiration for Erlang's methodology.
>
> But...
>
> I'm not seeing the cure-all, end-all, solution to concurrency problems, and
> it bothers me, because I'm probably missing something fundamental, something
> I should have picked up on, but didn't.
>
> Erlang allows other processes/threads to drop requests in an object's
> mailbox, but
> it also has a mechanism for waiting until the action is complete, as the
> "object"
> can send a response.
>
> It's this response wait that is the killer. Now, I've done a lot of work
> on/with Asterisk,
> and it is heavily mulithreaded, in the old-school way, and has a ton of
> critical
> sections, and locks, and mutiple locks for a single action. They have
> evolved
> some fairly involved strategies to avoid deadlocks, including putting a
> timer
> on the lock, and if it times out, giving up the lock they already have, and
> starting
> over, allowing the contending party to obtain the lock they need, finish
> their
> "thing", which allows you to continue and obtain the lock you need to do
> your
> "thing". And on and on it goes.
>
> Now, I didn't go and look up the particulars about "N-party dance", etc.,
> but
> the classic resource deadlock situations still seem
> in play when you have to wait for completion. A asks B to
> complete a task, and waits for him to respond. In order to get that done, B
> requests
> A for something, and waits forever for A to finish. And so on. Perhaps C or
> even D
> are also involved.
> I keep thinking that such basic situations
> aren't solved by
> switching to the Erlang methods. There must be some architectural, perhaps
> hierarchical organizing,
> some sort of general design practice, that can
> overcome these kinds of problems, I'm just blind to it at the moment.
>
> Situations like 'atomic' changes on two or more objects at once, etc. and I
> don't
> see in the fog, how Erlang solves these problems in general. Can someone
> point me to some literature that might make things clear?
>
> murf
>
> --
>
> Steve Murphy
> ParseTree Corporation
> 57 Lane 17
> Cody, WY 82414
> ✉  murf at parsetree dot com
> ☎ 307-899-5535
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list