One-shot semantics in GHC event manager
andreas.voellmy at gmail.com
Sat Oct 11 13:31:38 UTC 2014
On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> Thanks for your quick reply!
> Andreas Voellmy <andreas.voellmy at gmail.com> writes:
> > On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari <bgamari.foss at gmail.com>
> >> 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
> > system supports it.
> > You can always create your own EventManager using GHC.Event.Manager.new
> > 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
> * 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.
> - Ben
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs