[erlang-questions] deadlock (etc.) checking/avoidance?

[Lev Walkin]

Raoul Duke wrote:
> hi,
> 
> I've seen various things (Carlsson's paper, mention of Ostrovský's
> paper) but don't know of / are there any really production-ready tools
> or approaches for dealing with concurrency bugs like deadlock in
> Erlang? Or is there (not meant to be a slur) just some common
> un-theoretic approach where when a heartbeat fails things just get
> restarted and we assume it won't re-deadlock for ever?

In my experience, I have found that always having a timeout
(either implicitly via gen_server:call(), where we have 5s
default timeout, or explicitly with receive after X) and the linked
processes helps tremendously with catching and debugging the concurrency
problems. You just have to catch such errors and log them appropriately
to make sure you know about them eventually, even post factum.
Certainly, a supervision tree must be built while assuming that
the underlying processes _will_ fail, eventually, but not making
a big deal out of it.

Plus, some things like forwarding a setter/transaction
function instead of locking/modifying/unlocking the state
in a separate process help as well.

-- 
Lev Walkin
vlm@REDACTED