One-shot semantics in GHC event manager

[Andreas Voellmy]

On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:

> Andreas Voellmy <andreas.voellmy at gmail.com> writes:
>
> > On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari <bgamari.foss at gmail.com>
> wrote:
> >
> >> Thanks for your quick reply!
> >>
> >>
> >> 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.
> >
> Sure, I would certainly believe this.
>
> > 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.
> >
> I've started playing around with the code to see what might be possible
> here. We'll see how far I get.
>
> >> 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.
> >
> The system EventManager's loop is `GHC.Event.Manager.loop`, no?
>

Yes, but it will be invoked by GHC.Thread and any other callers of it will
simply block indefinitely waiting for the thread that is running loop to
give it up - which will typically never happen.

>
> > 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.
> >
> Right, but `GHC.Event.Manager` is not exported by `base`.
>

Ah... so this is not useful to you. I guess we could add `loop` to
GHC.Event's export list. On the other hand, I like your LifeTime proposal
better and then no one needs `loop`, so let's try this first.


>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141011/608c25d1/attachment.html>