Reader state gets "detached" when using withEffToIO

[tomjaguarpaw]

If I use local within a withEffToIO block (in this case printAsyncLocal) and then use that usage within another withEffToIO block then the Reader state gets "detached" from what it should be. Is there any choice of unlifting strategy parameters I can use to fix this?

Bluefin suffers from a similar issue. I realised this whilst discussing ghc-proposals/ghc-proposals#751, which offers a solution to this problem.

printAsyncLocal ::
  (IOE :> es, Reader Int :> es) =>
  Persistence ->
  Eff es r ->
  Eff es r
printAsyncLocal t2 m = do
  a <- withEffToIO (ConcUnlift t2 Unlimited) $ \effToIO -> liftIO $
    async $
      effToIO $
        local (+ 1) $ do
          (liftIO . print) =<< ask
          m

  liftIO (wait a)

-- Prints:
-- 1
-- 1
-- 1
-- Should be:
-- 1
-- 2
-- 3
withEffToIO (ConcUnlift t1 Unlimited) $ \effToIO ->
  useLocalIO (effToIO . printAsyncLocal t2 . liftIO)

Full code

{-# LANGUAGE GHC2021 #-}

import Control.Concurrent.Async (async, wait)
import Data.Foldable (for_)
import Effectful
  ( Eff,
    IOE,
    Limit (Unlimited),
    MonadIO (liftIO),
    Persistence (..),
    UnliftStrategy (ConcUnlift),
    runEff,
    withEffToIO,
    (:>),
  )
import Effectful.Reader.Static (Reader, ask, local, runReader)

-- Eff printLocal
-- 1
-- 2
-- 3
-- Eff printAsyncLocal Ephemeral
-- 1
-- 2
-- 3
-- Eff printAsyncLocal Persistent
-- 1
-- 2
-- 3
-- IO printLocal Ephemeral
-- 1
-- 2
-- 3
-- IO printLocal Persistent
-- 1
-- 2
-- 3
-- IO printAsyncLocal Ephemeral Ephemeral
-- 1
-- 1
-- 1
-- IO printAsyncLocal Ephemeral Persistent
-- 1
-- 1
-- 1
-- IO printAsyncLocal Persistent Ephemeral
-- 1
-- 1
-- 1
-- IO printAsyncLocal Persistent Persistent
-- 1
-- 1
-- 1
main :: IO ()
main = runEff $ runReader 0 $ do
  liftIO (putStrLn "Eff printLocal")
  useLocal printLocal

  for_ [Ephemeral, Persistent] $ \t1 -> do
    liftIO (putStrLn ("Eff printAsyncLocal " <> show t1))
    useLocal (printAsyncLocal t1)

  for_ [Ephemeral, Persistent] $ \t1 -> do
    liftIO (putStrLn ("IO printLocal " <> show t1))
    withEffToIO (ConcUnlift t1 Unlimited) $ \effToIO ->
      useLocal (effToIO . printLocal . liftIO)

  for_ [Ephemeral, Persistent] $ \t1 -> do
    for_ [Ephemeral, Persistent] $ \t2 -> do
      let options = show t1 <> " " <> show t2
      liftIO (putStrLn ("IO printAsyncLocal " <> options))
      withEffToIO (ConcUnlift t1 Unlimited) $ \effToIO ->
        useLocal (effToIO . printAsyncLocal t2 . liftIO)

useLocal :: Applicative m => (forall a. m a -> m a) -> m ()
useLocal myLocal = do
  myLocal $
    myLocal $
      myLocal $
        pure ()

printLocal ::
  (IOE :> es, Reader Int :> es) =>
  Eff es r ->
  Eff es r
printLocal m = do
  local (+ 1) $ do
    (liftIO . print) =<< ask
    m

printAsyncLocal ::
  (IOE :> es, Reader Int :> es) =>
  Persistence ->
  Eff es r ->
  Eff es r
printAsyncLocal t2 m = do
  a <- withEffToIO (ConcUnlift t2 Unlimited) $ \effToIO -> liftIO $
    async $
      effToIO $
        local (+ 1) $ do
          (liftIO . print) =<< ask
          m

  liftIO (wait a)

[arybczak]

Is there any choice of unlifting strategy parameters I can use to fix this?

Not in this particular case, no.

  for_ [Ephemeral, Persistent] $ \t1 -> do
    for_ [Ephemeral, Persistent] $ \t2 -> do
      let options = show t1 <> " " <> show t2
      liftIO (putStrLn ("IO printAsyncLocal " <> options))
      withEffToIO (ConcUnlift t1 Unlimited) $ \effToIO -> -- (*)
        useLocal (effToIO . printAsyncLocal t2 . liftIO)

At (*) withEffToIO captures the current environment, for which the Reader's value is 0. Then you keep calling the unlifting function effToIO (since you use it in an argument to useLocal) every time in a new thread spawned by async, so the unlifting function restores the environment captured at this point, because that's the only thing it can do.

I realised this whilst discussing ghc-proposals/ghc-proposals#751, which offers a solution to this problem.

This is a nice proposal, but IIUC it currently only works out of the box for thread-local immutable data. It won't work as expected for mutable data such as IORef, because for such data a deep copy needs to be performed when forking.

Proper support for mutable data would need a custom t -> IO t function (e.g. from a dedicated type class) executed for each thread local data t at every fork, e.g. for IORef it needs to do newIORef and copy contents, for MVar newMVar and copy contents etc.

[arybczak]

FWIW, even if the proposal supported thread local mutable data, it won't work for bluefin, because you can have multiple effects of the same type in scope and thread local storage allows only one.

But it also doesn't work for effectful, because the captured environment is not thread-local, it has to be local to the unlifting function. This would happen if it was thread-local:

heh :: IO ()
heh = runEff $ do
  runReader 'x' $ do
    -- (1) Captures the environment as a thread-local data.
    withEffToIO $ \unlift1 -> do
      runEff . runState "blah" $ do
        -- (2) Captures a completely different environment as a thread-local
        -- data, overwrites capture done by (1).
        withEffToIO $ \unlift2 -> do
          async $ do
            -- Unlifting function takes the thread-local environment, but it's
            -- the wrong one, because it was overwritten by (2).
            unlift1 $ do
              -- Boom!
              ask @Char

[tomjaguarpaw]

even if the proposal supported thread local mutable data, it won't work for bluefin, because you can have multiple effects of the same type in scope and thread local storage allows only one

As far as I can tell that's not a limitation because I can have an effect of type BluefinScope in scope and then just put all my other effects in there.

[arybczak]

Hmm, although maybe a single value is not a limitation since you can attach uniques to entities (such as effect data or unlifting functions) and store appropriate thread-local data in a Map 🤔

In this case might be worth it to pitch support for mutable data structures in the proposal.

[tomjaguarpaw]

Do you need a mutable data structure to be provided by the proposal? Can't you put anything you want to mutate inside an IORef, or whatever, inside the immutable structure?

[arybczak]

Can't you put anything you want to mutate inside an IORef, or whatever, inside the immutable structure?

If I do that, I get the same IORef in the child thread as the parent has and thus it might have been already modified (or is currently being modified) by the parent, so it can't be relied on.

Looks like the proposal won't help here (since it won't have deep copy support, which is fair, it's a specific use case).

In any case, there is no bug here. Maybe slight deficiency of the unlifting mechanism, but you get what you request: environment captured at the point of creating the unlifting function.