
Thanks for your quick reply!
Andreas Voellmy
On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari
wrote: I'm a bit perplexed as to why the change was made in the way that it was. Making one-shot a event-manager-wide attribute seems to add a fair bit of complexity to the subsystem while breaking backwards compatibility with library code.
It added some complexity to the IO manager, but that should not affect clients except those using the internal interface.
What I'm wondering is what the extra complexity bought us. It seems like the same thing could have been achieved with less breakage by making this per-fd instead of per-manager. I may be missing something, however.
Going forward library authors now need to worry about whether the system event manager is one-shot or not.
Yes, but only library authors using the internal interface.
Not only is this platform dependent but it seems that there is no way for a user to determine which semantics the system event handler uses.
Is there a reason why one-shot wasn't exported as a per-fd attribute instead of per-manager? Might it be possible to back out this change and instead add a variant of `registerFd` which exposes one-shot semantics?
The system event manager is configured by GHC.Thread using ONE_SHOT if the system supports it.
You can always create your own EventManager using GHC.Event.Manager.new or GHC.Event.Manager.newWith functions. Those functions take a Bool argument that control whether ONE_SHOT is used by the Manager returned by that function (False means not to use ONE_SHOT). Would this work for usb?
I had considered this but looked for other options for two reasons, * `loop` isn't exported by GHC.Event * there is already a perfectly usable event loop thread in existence I'm a bit curious to know what advantages ONE_SHOT being per-manager carries over per-fd. If the advantages are large enough then we can just export `loop` and be done with it but the design as it stands strikes me as a bit odd. Cheers, - Ben