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.
Currently,
registerDelayis implemented in function of what's provided byMonadConc, forking a thread. This works, but theregisterDelayimplementation from GHC/stmis 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
registerDelayinMonadConcso theIOinstance can use the one fromstm, andProgramthe current implementation (using a thread)? Operationally, both should be the same (otherwise theregisterDelayinconcurrencywouldn't be interchangable with the one fromstmin the first place...), so tests using DejaFu should still find bugs, even when inIOanother implementation is used.