3 ms·
``` Whenever you message another process and need a reply there is a risk of deadlock. ``` can you please explain how there is risk of deadlock here
by signa11 1y ago
```
Whenever you message another process and need a reply
there is a risk of deadlock.
```
can you please explain how there is risk of deadlock here ? thanks !
- jhgg 1y agoRisk 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 1y agoreceive takes a timeout. A would crash/hit the timeout and deal with the problem.
- jhgg 1y agoYes, agreed, hence rarely a problem in practice ;)
- signa11 1y agoyou are not blocked on response right ?
- worthless-trash 1y agoYou can cast or call ( non blocking, or blocking) you can do either.
- signa11 1y agohow would you get a deadlock with non-blocking requests ?
- worthless-trash 1y agoI never said you did ?
- signa11 1y agonot 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 1y agoOh, 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.
- innocentoldguy 1y agoWouldn't you just `cast` instead of `call` if you thought this was going to be an issue?