[zeromq-dev] Erlang style messaging
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:
>> Last year, I read the book, Programming Erlang, by Joe Armstrong, and I
>> fascinated by the ideology behind the general thread-per-object approach,
>> 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.
>> I'm not seeing the cure-all, end-all, solution to concurrency problems,
>> it bothers me, because I'm probably missing something fundamental,
>> 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
>> 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
>> sections, and locks, and mutiple locks for a single action. They have
>> some fairly involved strategies to avoid deadlocks, including putting a
>> 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
>> "thing", which allows you to continue and obtain the lock you need to do
>> "thing". And on and on it goes.
>> Now, I didn't go and look up the particulars about "N-party dance", etc.,
>> 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?
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev