One-shot semantics in GHC event manager

[Andreas Voellmy]

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>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141011/f685d2a5/attachment.html>