26 ms·

While I don’t know Haskell or GHC, that sounds like a bug in the runtime. My understanding: - Deadlock detection is a feature some language runtimes can provi

by klabb3 3y ago

While I don’t know Haskell or GHC, that sounds like a bug in the runtime. My understanding: - Deadlock detection is a feature some language runtimes can provide. - To my knowledge there’s no reasonable path of recovery from within the process (broad sense of the term) itself. - If you have process isolation then a parent or supervisor can kill and respawn. (Is this what Erlang does?) - Deadlocks are only theoretically detectable in the cases where the runtime can trace the “path” to something it knows about. This may include runtime objects like channels and mutices, but certainly does not include IO etc. For example: program is currently waiting on a tcp socket with no timeout. - As such, deadlock detection is at most moderately useful for typical application debugging and development workflows. Personally I would much rather have easy access to a “what are processes currently blocked on” list than “the runtime is so smart it will error out automagically” kind of thing.

ReleaseCandidat 3y ago
> While I don’t know Haskell or GHC, that sounds like a bug in the runtime. That's what the article is about, workarounds for that problem (that has been known for 8 years now). https://gitlab.haskell.org/ghc/ghc/-/issues/10793 https://gitlab.haskell.org/ghc/ghc/-/issues/10793
loeg 3y ago
A slightly different form of deadlock detector can still be really useful for portions of the system that are not unbounded network IO. I agree that predicting forward progress from in-memory state like Haskell seems to be doing is more or less useless in the presence of IO. But you can instead use some measure of forward progress and a simple long timeout (like 10-60 seconds) to empirically determine the system is stalled. E.g., you might reasonably implement timeouts on slow network clients or otherwise have a way to idle them, so it is still a problem if the system does not make forward progress in 10 seconds or whatever. Or if your service manages all access to disk, you can expect bounded IO from disks that have not failed. Then you can take some debugging action (development) or maybe restart the service (prod) or some combination of the above when a deadlock is detected in an empirical way (no forward progress in a time period).

by klabb3 3y ago

ReleaseCandidat 3y ago

> While I don’t know Haskell or GHC, that sounds like a bug in the runtime. That's what the article is about, workarounds for that problem (that has been known for 8 years now). https://gitlab.haskell.org/ghc/ghc/-/issues/10793 https://gitlab.haskell.org/ghc/ghc/-/issues/10793

loeg 3y ago

A slightly different form of deadlock detector can still be really useful for portions of the system that are not unbounded network IO. I agree that predicting forward progress from in-memory state like Haskell seems to be doing is more or less useless in the presence of IO. But you can instead use some measure of forward progress and a simple long timeout (like 10-60 seconds) to empirically determine the system is stalled. E.g., you might reasonably implement timeouts on slow network clients or otherwise have a way to idle them, so it is still a problem if the system does not make forward progress in 10 seconds or whatever. Or if your service manages all access to disk, you can expect bounded IO from disks that have not failed. Then you can take some debugging action (development) or maybe restart the service (prod) or some combination of the above when a deadlock is detected in an empirical way (no forward progress in a time period).