Skip to content

CPU burning loop when should be blocked on recv?

Summary

I have a pretty simple application that uses web sockets (websockets + wuss packages) to tunnel data. At the core there are two threads that read and write from the web socket. After some period of activity it seems to get stuck in a loop that consumes 100% CPU (1 CPU core) when it should rather be blocked on recv.

If you look at the +RTS -Ds output you would notice that IOManager thread constantly wakes up and goes to sleep, with the GC getting triggered from time to time. What's weird is that even though IOManager thread apparently does some work no other thread gets waken up to consume the results.

I have attached +RTS -Ds, dtruss and profile output (with <0.3% items filtered out).

ds.txt dtruss.txt zaloopa-client-exe.prof

Steps to reproduce

Having recv and send going on at the same websocket.

Expected behavior

Block with zero CPU usage.

Environment

  • GHC version used: 8.6.5 (Stack LTS-13.27), tried 8.4.4 (Stack LTS-12.26) with the same effect.

Optional:

  • Operating System: macOS Mojave 10.14.5
  • System Architecture: x64
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information