On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari <bgamari.f...@gmail.com> 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. Yes. > It appears this was done to optimize the > common case of file I/O where only a single event is needed > Yes. > > 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 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? -Andi > Cheers, > > - Ben > > > [1] https://github.com/basvandijk/usb/issues/7 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs