[dnautics]

Single threaded service a sends a call request to service b, as a part of handling the request, service b requests back to service a. Deadlock.

You may not have control over service b.

[signa11]

huh :) if you have async-messages without any blocking semantics you are just fine.

[dnautics]

My point is just that it's possible to construct one in any system that static analysis will be unable to detect or prevent. If you can construct it, it can also happen by accident.

[signa11]

> My point is just that it's possible to construct one in any system that static analysis will be unable to detect or prevent. If you can construct it, it can also happen by accident.

how ? can you please explain ? thanks !

[dnautics]

most people implement "block on API response", because that's way easier to reason about, sometimes, even without timeout. Reading through the thread, what I was misunderstanding is that this situation technically gets rolled into what called a "livelock". Fine, but from the higher-level API consumer's POV it's a deadlock.

[signa11]

with blocking semantics, you are sure to run into deadlocks in a single-threaded environment pretty easily a -> b -> c -> a.

grpc f.e. has support for blocking requests but it's 'solution' is to spawn a new thread for the request.

[senderista]

You did not construct such a scenario for an async message-passing system.