[jhgg]

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.

[oxidant]

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

[jhgg]

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

[innocentoldguy]

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

[signa11]

you are not blocked on response right ?

[worthless-trash]

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

[signa11]

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

[worthless-trash]

I never said you did ?

[signa11]

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.

[worthless-trash]

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.