On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari <bgamari.f...@gmail.com> wrote:
> 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. > > Generally, ONE_SHOT helped improve performance. I agree with you that it may be possible to do this on a per-FD basis. I'll look into what it would take to do this. > > > >> 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 > Right - it wouldn't make sense to export the system EventManager's loop. However, the GHC.Event.Manager module does export its loop function, so if you create your own non-ONE_SHOT event manager, you can just invoke its loop function. > * 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. > I suspect that a per-FD design would perform just as well, but I need to look at the details to be sure. Cheers, > > - Ben > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs