Thanks for your quick reply!
Andreas Voellmy <andreas.voel...@gmail.com> writes: > On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari <bgamari.f...@gmail.com> 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
pgpNS_u4oNKLF.pgp
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
