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

Andreas Voellmy <andreas.voellmy@gmail.com> writes:

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