Actually, I think I came up with a solution on the way home from work today. Instead of
data Future t a = Fut { waitFor :: t -> STM () , value :: STM (t, a) }
I will use
data Future t a = Fut { waitFor :: t -> IO (STM ()) , value :: IO (STM (t, a)) }
The goal is to be able to wait on multiple things at a time, but that
doesn't mean all the setup has to happen in STM. Now I can setup some
TVars in IO and then hand-off to STM for the niceness of "orElse".
-- ryan
On Tue, Apr 22, 2008 at 6:46 PM, Matthew Brecknell
Ryan Ingram said:
retryUntil :: TVar a -> (a -> Bool) -> STM ()
[...]
the semantics would be that the transaction log, instead of saying "I read from v" would say "I read from v and failed because v didn't satisfy this predicate".
Changes to any other variable in the log would have the same effect as always: restarting the transaction. This is actually required in my desired use case; I want to block until "now" becomes >= t, or a different TVar gets filled with a non-Nothing value.
I see now what you mean, and I can see that it might be a nice little addition. By giving the STM runtime additional information about what conditions would allow the transaction to progress, it might be able to save some false retries. Note that the only work that is saved is the work done to get to the retryUntil.
However, strictly speaking, the STM runtime doesn't need this additional information. You could view a composite STM transaction as an inverted tree, with individual reads at the leaves, merging through monadic bindings towards the root, which is the final result (which includes the transaction's atomic updates). A transaction waiting on a retry is just one of these trees in suspended animation, waiting for a new value to be written to one of the leaves. When such a value is written to one of the leaves, only its downstream nodes need re-evaluation.
Implementing STM that way may not be worth the effort, though, whereas retryUntil might be.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe