Add generic hooks to mainloop#120
Conversation
|
Forgot to add: this does not touch the |
|
The Also, a small benchmark to check what the straightline performance hit of this is, since it's activated on every scheduler activation. In particular, if we don't currently use the exit code, we shouldn't add it to our fast path. |
|
In a tight loop, the overhead of each hook construct alone (iteration over a globally stored empty sequence) is:
... on my machine. Simply reading the cycle counter with a pipeline flush ( Performance-wise, I'm far more concerned about what happens inside the hooks. Please note that all of this already happens if you run On the exception front, I followed the existing The numbers don't really show that it's costly to keep the exit hook, but if you are still concerned, I'm happy to remove it. |
Adds the interface to register hooks that are always called from the main loop, irrespective of the event source. Usable for hooking up background tasks which depend on generic activity, but not on any specific event source.
This facility is required for proper entropy support: it is used to gather (hopefully) not-quite-deterministic inter-event timings and to arrange for periodic entropy harvesting from other sources without unduly waking up an otherwise idle system.
The API mirrors
Lwt_main.enter_iter_hooks/Lwt_main.leave_iter_hooks, except that for the sake of simplicity and abstraction, instead of the fullLwt_sequence, only the hook registration is exposed. On unix, it actually defers to the equivalent facility inLwt_main; on xen, it implements it in a similar way.The choice of handlers not returning an
Lwt.treflects the fact that these hooks are not going to be synchronized on, and should probably not take long anyway. It's also possible to start an lwt thread in them usingLwt.async.Strictly speaking, the entropy business only needs the enter hook, but its dual is provided for completeness.
This is running in the BTC Piñata. No nasal demons were registered thus far.