One-shot semantics in GHC event manager

Andreas Voellmy andreas.voellmy at
Sat Oct 11 04:41:28 UTC 2014

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

> In ba2555ef and a6f52b19 one-shot semantics were added to event manager
> in `base`. If my understanding of this code is correct, in this mode the
> event manager will use only notify the user of the first event on a
> registered fd after which point the fd will need to be re-registered to
> get another notification.


> It appears this was done to optimize the
> common case of file I/O where only a single event is needed


> This change lead to a regression[1] in Bas van Dijk's usb library under
> GHC 7.8. usb's use of the event manager requires that all events on an
> fd are reported until the fd is registered or else hardware events are
> lost.

The change should only affect libraries using GHC.Event (or other modules
underneath), which are exposed, but considered "internal". I searched
hackage before making this change and usb was the only library that came up
using GHC.Event directly. I'm not sure if I sent the usb maintainers an
email now... I really should have done that to save you the effort of
hunting down the problem in usb.

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

> 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 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?


> Cheers,
> - Ben
> [1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list