On Fri, Aug 29, 2014 at 7:40 PM, Steve Murphy <[email protected]> wrote:
> However, Erlang does not avoid all problems associated with concurrent > execution. In particular, it provides for interactions and communication > patterns between processes that may be stuck in their execution until > some conditions are met, hence allowing certain kinds of deadlocks in > programs. First off, there's a good Erlang users list where you can ask this kind of question and get a response from the right people. Second, this sounds like scaremongering. Someone is trying to sell a solution to a pseudo problem, so they're creating drama. "Oooh, things could possibly go wrong!" Yes, any concurrent architecture could, potentially, get deadlocks if you set things up just right. However in practice, that's not what we see. The Internet does not deadlock. We don't deadlock while processing email. Real life does not deadlock, and actors approach real life quite closely in many ways. Actors block in the sense that they wait for work. However they do not block waiting for access to data, while trying to work. This is a profound difference. When an actor has work to do, nothing should be able to stop it. Yes, you can create interdependencies that cause deadlocking, however this is a pathological case. Anyhow, I don't think this kind of philosophy has much use. Write code, try to solve useful problems, improve your code carefully and without haste. If you can show a problem of deadlocking in an actor model, that would be useful input. The philosophy of maybes is, in my view, pointless. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
