[zeromq-dev] Erlang style messaging

Thomas Rodgers rodgert at twrodgers.com
Thu Aug 28 23:53:08 CEST 2014


FWIW, Erlang's gen_server behavior supports a call() form which takes a
timeout (by default infinity).  If the call times out, the call fails with
an exception, unless you catch this (not the usual Erlang way) the process
initiating the call will terminate, propagating the failure to any other
linked process.  If the population of processes that *might* deadlock are
part of the same supervisor tree, the supervisor behavior can recover from
this deadlock condition at this point by terminating all processes and
restarting them.


On Thu, Aug 28, 2014 at 9:58 AM, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140828/734f1736/attachment.html>


More information about the zeromq-dev mailing list