Re: One-shot semantics in GHC event manager

On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari wrote:

Andreas Voellmy writes:

...

On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari 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