Hi Ben,
> This is generally in the direction I proposed in #21877; I agree that it
> would be quite useful. I don't think that we necessarily want to extend
> all MVars with labels as this would impose a fixed memory cost on all
> users. However, I think the approach that I describe in the ticket,
"Kazu Yamamoto \(山本和彦\) via ghc-devs" writes:
> Hello,
>
> I'm seeking of the source of the bug that my server based on Warp gets
> not-responding. "listThreads" shows that IOManager is blocked on a
> MVar permanently:
>
> 2 IOManager on cap 0: ThreadBlocked BlockedOnForeignCall
> 3 IOManager on
Hi Kazu,
This sounds like something you could investigate with ghc-debug. Once the
mvar blocks you can look at the stack using ghc-debug-brick which should be
enlightening.
Matt
On Wed, 20 Nov 2024, 01:17 Kazu Yamamoto (山本和彦) via ghc-devs, <
ghc-devs@haskell.org> wrote:
> Hello,
>
> I'm seeking
Hello,
I'm seeking of the source of the bug that my server based on Warp gets
not-responding. "listThreads" shows that IOManager is blocked on a
MVar permanently:
2 IOManager on cap 0: ThreadBlocked BlockedOnForeignCall
3 IOManager on cap 1: ThreadBlocked BlockedOnMVar
4 TimerManager: ThreadBlock
