One-shot semantics in GHC event manager

[Ben Gamari]

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.

>
>> 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
 * 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.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141011/33f5cf4d/attachment.sig>