-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
threadDelay & registerDelay - unbounded delays #2135
Conversation
@mrBliss there's a CI failure in Byron test suite: https://hydra.iohk.io/build/2717445/nixlog/3 |
If |
Locally, it run fine:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
We should also remove the duplicate implementation in the consensus code.
For delays smaler than 'maxBound :: Int', we use 'Control.Monad.STM.registerDelay'; for larger delays we start a monitoring thread which will update the returned 'TVar' (re-using the default implementation).
bors merge |
2135: threadDelay & registerDelay - unbounded delays r=coot a=coot This PR updates both `threadDelay` and `registerDelay`. Both accept `DiffTime`, and they should be safe. `threadDelay` is easy, since it's a synchronous operation; `registerDelay` is more tricky as the returned `TVar` must be updated asynchronously. For delays smaller than `maxBound :: Int` we reuse the original `STM` implenetation, for larger delays we use the default 'MonadTimer` implementation (which starts a thread to update the `TVar`). - registerDelay - accept unbounded delays - threadDaley - accept unbounded delays Co-authored-by: Marcin Szamotulski <profunctor@pm.me>
2162: Undo MonadDelay wrapper r=mrBliss a=kderme After IntersectMBO/ouroboros-network#2135 the wrapper is no longer needed. Undoes IntersectMBO/ouroboros-network#2095 Co-authored-by: kderme <k.dermenz@gmail.com>
This PR updates both
threadDelay
andregisterDelay
. Both acceptDiffTime
, and they should be safe.threadDelay
is easy, since it's a synchronous operation;registerDelay
is more tricky as the returnedTVar
must be updatedasynchronously. For delays smaller than
maxBound :: Int
we reuse the originalSTM
implenetation, for larger delays we use the default 'MonadTimerimplementation (which starts a thread to update the
TVar`).