10 ms·
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
by jhgg 11mo ago
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 11mo agoreceive takes a timeout. A would crash/hit the timeout and deal with the problem.
- jhgg 11mo agoYes, agreed, hence rarely a problem in practice ;)
- signa11 11mo agoyou are not blocked on response right ?
- worthless-trash 11mo agoYou can cast or call ( non blocking, or blocking) you can do either.
- signa11 11mo agohow would you get a deadlock with non-blocking requests ?
- worthless-trash 11mo agoI never said you did ?
- signa11 11mo 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 11mo 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 11mo agoWouldn't you just `cast` instead of `call` if you thought this was going to be an issue?