Risk of deadlock is real if you have processes calling each-other in a cyclic way. e.g. process A sends GenServer call to process B, that then sends a GenServer call to process A to in order to handle the original call. However, process A is busy waiting on B to reply to it's initial call.

This is rarely a problem in practice however.

receive takes a timeout. A would crash/hit the timeout and deal with the problem.

Yes, agreed, hence rarely a problem in practice ;)

Wouldn't you just `cast` instead of `call` if you thought this was going to be an issue?

you are not blocked on response right ?

You can cast or call ( non blocking, or blocking) you can do either.

how would you get a deadlock with non-blocking requests ?

I never said you did ?

not you per-se no.

but this whole thread started with deadlock on remote calls, and i was curious about how that could be with async calls.

Oh, I think that the mailbox access a process has can wont block unless its full, in which case the message will be dropped.

I think you can check message_queue_len using erlang:process_info/2 to find the mailbox size and simply back off, or fail noisly.