Re: One-shot semantics in GHC event manager

On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari wrote:

Thanks for your quick reply!

Andreas Voellmy writes:

...

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