Global IORefs + Circular dep = surprising behavior?

brandonchinn178 · November 4, 2023, 12:53am

Global IORefs + Circular dep = surprising behavior?

opened 12:53AM - 04 Nov 23 UTC

# Overview Ran into this at work, I find it surprising behavior, even if it's… understandable. I think _something_ could/should be done here, but not sure what. At a high level, if I create a global IORef with `unsafePerformIO` in one package, use it in another package, and then rebuild the first package, the second package is using a different IORef than the rest of the program would be using. In our case, we have a dependency chain ``` pkg-a:lib │ └─> pkg-b:lib │ ↓ └─> pkg-a:test-suite ``` Where Stack builds `pkg-a:lib`, then builds `pkg-b:lib` against `pkg-a:lib (1)`, then rebuilds `pkg-a:lib` and builds `pkg-a:test-suite` against `pkg-a:lib (2)`. Cabal just flat rejects the circular dependency, but Stack recognizes that the components are linearizable. The problem is Stack recompiling the library. # Minimal repro ```cabal -- my-lib/my-lib.cabal cabal-version: 3.0 name: my-lib version: 0 build-type: Simple library exposed-modules: MyLib build-depends: base test-suite my-lib-tests type: exitcode-stdio-1.0 main-is: Test.hs build-depends: base, my-lib, my-test-utils ``` ```hs -- my-lib/MyLib.hs module MyLib where import Data.IORef import System.IO.Unsafe myRef :: IORef Int myRef = unsafePerformIO $ newIORef 0 {-# NOINLINE myRef #-} readRefFromLib :: IO () readRefFromLib = do x <- readIORef myRef putStrLn $ "readRefFromLib: " <> show x ``` ```cabal -- my-test-utils/my-test-utils.cabal cabal-version: 3.0 name: my-test-utils version: 0 build-type: Simple library exposed-modules: MyTestUtils build-depends: base, my-lib ``` ```hs -- my-test-utils/MyTestUtils.hs module MyTestUtils where import Data.IORef import MyLib writeRefFromTestUtils :: IO () writeRefFromTestUtils = do writeIORef myRef 123 x <- readIORef myRef putStrLn $ "writeRefFromTestUtils: " <> show x ``` ```hs -- my-lib/Test.hs import MyLib import MyTestUtils main :: IO () main = d readRefFromLib writeRefFromTestUtils readRefFromLib ``` ## Expected ``` readRefFromLib: 0 writeRefFromTestUtils: 123 readRefFromLib: 123 ``` ## Actual ``` readRefFromLib: 0 writeRefFromTestUtils: 123 readRefFromLib: 0 ```

atravers · November 4, 2023, 1:56am

I’m going to have a half-educated guess here: despite using {-# NOINLINE #-} to prevent it, myRef is still being copied.

Out of curiosity, what happens when the obligatory “read/write duo” is used instead of exporting myRef?

module MyLib (
  readMyRef,      -- :: IO Int
  writeMyRef,     -- :: Int -> IO () 
  readRefFromLib  -- :: IO ()
) where
         ⋮ 
readRefFromLib =
 do x <- readMyRef
    putStrLn $ "readRefFromLib: " <> show x

brandonchinn178 · November 4, 2023, 2:23am

That’s actually closer to what my original code at work was, and it does make the problem much more obvious / surprising. The same thing happens with your example. I’ll update the issue with that example, thanks!

atravers · November 4, 2023, 4:37am

Hrm - following a "trail of crumbs" has lead to this post:

https://github.com/commercialhaskell/stack/issues/2904#issuecomment-284944974

But at least @taylorfausak’s observation from:

https://github.com/commercialhaskell/stack/issues/3130

suggests the problem exists independently of the circular dependency in your example (and the use of top-level IORefs) - you can now produce a smaller MRE.

tomjaguarpaw · November 4, 2023, 8:57am

I’m not surprised that a “global” IORef (allocated with unsafePerformIO) leads to “surprising” behavior I strongly recommend to not do that!

atravers · November 4, 2023, 9:58am

…because top-level MVars at least provide basic concurrent access? :-P

I’m going to speculate that, due to helpful articles like:

…the majority of Haskellers are quite aware of the problems that this combination can cause.

brandonchinn178 · November 4, 2023, 5:21pm

I mean, it normally works. It’s a useful hack to inject things only for tests. The only reason it fails to work here is because of Stack rebuilding and linking things incorrectly.

But I’ve actually gotten a smaller repro without a mutable IORef (although the mutable IORef makes the issue much less obvious). I updated the GitHub issue