labeling MVar and STM data structures

[Ben Gamari]

"Kazu Yamamoto \(山本和彦\) via ghc-devs" <ghc-devs at haskell.org> 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 cap 1: ThreadBlocked BlockedOnMVar
> 4 TimerManager: ThreadBlocked BlockedOnForeignCall
>
> IOManager should have the BlockedOnForeignCall reason since it's
> calling epoll_wait().
>
> It's quit hard to debug this bug since I don't understand which MVar blocks
> IOManager of 3. Users can register MVar operations to IOManager while
> IOManager itself is using MVars internally.
>
> To make this kind of debugging easier, I would like ask GHC developers
> to extend MVar to hold its label and provide "labelMVar" like
> "labelThread". The same mechanism should be provided for STM as well.
> "BlockReason" should contain the target label.
>
> What do you think?

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,
introducing an out-of-band map for labelling heap objects, would be
a reasonable way forward.

As Matt suggests, ghc-debug is also a great tool for investigating
issues like this. However, I still think there is value in having better
support in the core libraries for understanding issues such as this.

Thoughts?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241120/b6a6efaf/attachment.sig>