[zeromq-dev] Erlang style messaging

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

I guess one other point - IMO it's important to understanding the "Erlang
way" to look past just the message and light weight process bits, to
various behaviors - gen_server and supervisor in particular to understand
how Erlang handles faults and recovery.

On Thu, Aug 28, 2014 at 4:53 PM, Thomas Rodgers <rodgert at twrodgers.com>

> 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/db89dc60/attachment.html>

More information about the zeromq-dev mailing list