Thanks everyone for the helpful suggestions!
Bryan Richer wrote:
> what if the TVar is part of the
> state s?
> (StateT IO) can't give any guarantees about when or how the state is
> broadcast, but using STM within StateT actions still can.
I don't understand this, but it may go into the same direction as:
Chris Smith wrote:
> I had the same suggestion. However, you then no longer need StateT, as
> ReaderT is enough. Using a `ReaderT (TVar s) IO a` will allow atomic
> changes to the state s, along with interleaved IO when it's done safely
> rather than in the middle of a transaction.
ReaderT (TVar s) IO is interesting! It does not solve the problem of
atomic modifications with side-effects, though. Currently I am
implicity using ReaderT (TVar s), by explicitly passing the TVar
around.
In principle, for atomic modifications I have to get hold of a pure
version (s -> s) of the modification. Maybe within a monadic context.
But if determining this modification function is side-effectful, then
it can not depend on the initial contents of the TVar!
This leads me to the conclusion that either
(a) atomic modification by a Kleisli map is impossible and another
mechanism needs to ensure thread safety, or
(b) we need to keep two versions of the state: one private, pure s and
one public TVar s which we synchronize from time to time. The latter
can be accomplished with atomic writes. More on that below.
Isaac Elliott wrote:
> What about creating a MonadState instance for the TVar?
Very neat, but it would not solve the atomicity problem, since the
update I have is not expressible as stateTVar.
YueCompl wrote:
> I believe this is the use case for TMVar, use `takeTMVar` / `putTMVar` instead of `readTVar` / `writeTVar` will do.
TMVars appear non-empty for one thread only, as far as I understand.
So any observer thread would be blocked while the worker thread is
updating the state?
Not good for my use case. The observer thread will be a webserver.
I'd rather have the webserver report old states than block.
I have neglected to mention one aspect of my problem that might be
essential: All my state updates are monoidal. By that I mean that s is
a monoid with
s' <> s <> s = s' <> s
and any effectful modification will be of the form
f = \s -> (k s) >>= (\s' -> s' <> s)
for some k :: s -> m s.
This entails that instead of emitting modifications as functions I can
emit modifications as values.
emitModification :: (Monad m, Monoid s) =>
StateT s m a -> WriterT s (StateT s m) a
emitModification (StateT f) = WriterT $ StateT $ \s -> do
(a,s') <- f s
return ((a,s'),s')
broadcastModification :: (MonadIO m, Semigroup s) =>
TVar s -> (WriterT s m) a -> m a
broadcastModification ref (WriterT m) = do
(a,s') <- m
(liftIO.atomically) (modifyTVar ref (\s -> s' <> s))
return a
Then
\ref -> broadcastModification ref . emitModification
:: (MonadIO m, Monoid s) =>
TVar s -> StateT s m a -> StateT s m a
This has the additional charm that I can explicitly control when writes
to the TVar happen, by choosing which (StateT s m) blocks to enclose in
this wrapper. I might even set up my communication as a TChan, if the
observing thread maintains an own copy of state itself to merge the
updates s' into.
Olaf
