You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, registerDelay is implemented in function of what's provided by MonadConc, forking a thread. This works, but the registerDelay implementation from GHC/stm is quite different: it schedules something in the runtime's timer manager to get things done at some future point in time, removing the need for a thread.
Would it make sense to have registerDelay in MonadConc so the IO instance can use the one from stm, and Program the current implementation (using a thread)? Operationally, both should be the same (otherwise the registerDelay in concurrency wouldn't be interchangable with the one from stm in the first place...), so tests using DejaFu should still find bugs, even when in IO another implementation is used.
The text was updated successfully, but these errors were encountered:
Currently,
registerDelay
is implemented in function of what's provided byMonadConc
, forking a thread. This works, but theregisterDelay
implementation from GHC/stm
is quite different: it schedules something in the runtime's timer manager to get things done at some future point in time, removing the need for a thread.Would it make sense to have
registerDelay
inMonadConc
so theIO
instance can use the one fromstm
, andProgram
the current implementation (using a thread)? Operationally, both should be the same (otherwise theregisterDelay
inconcurrency
wouldn't be interchangable with the one fromstm
in the first place...), so tests using DejaFu should still find bugs, even when inIO
another implementation is used.The text was updated successfully, but these errors were encountered: