<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari <span dir="ltr"><<a href="mailto:bgamari.foss@gmail.com" target="_blank">bgamari.foss@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In ba2555ef and a6f52b19 one-shot semantics were added to event manager<br>
in `base`. If my understanding of this code is correct, in this mode the<br>
event manager will use only notify the user of the first event on a<br>
registered fd after which point the fd will need to be re-registered to<br>
get another notification. </blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It appears this was done to optimize the<br>
common case of file I/O where only a single event is needed<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This change lead to a regression[1] in Bas van Dijk's usb library under<br>
GHC 7.8. usb's use of the event manager requires that all events on an<br>
fd are reported until the fd is registered or else hardware events are<br>
lost.<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm a bit perplexed as to why the change was made in the way that it<br>
was.  Making one-shot a event-manager-wide attribute seems to add a fair<br>
bit of complexity to the subsystem while breaking backwards<br>
compatibility with library code. </blockquote><div><br></div><div>It added some complexity to the IO manager, but that should not affect clients except those using the internal interface. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Going forward library authors now need<br>
to worry about whether the system event manager is one-shot or not. </blockquote><div><br></div><div>Yes, but only library authors using the internal interface.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not<br>
only is this platform dependent but it seems that there is no way for a<br>
user to determine which semantics the system event handler uses. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is there a reason why one-shot wasn't exported as a per-fd attribute<br>
instead of per-manager? Might it be possible to back out this change and<br>
instead add a variant of `registerFd` which exposes one-shot semantics?<br>
<br></blockquote><div><br></div><div>The system event manager is configured by GHC.Thread using ONE_SHOT if the system supports it. </div><div><br></div><div>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? <br></div><div><br></div><div>-Andi</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
<br>
- Ben<br>
<br>
<br>
[1] <a href="https://github.com/basvandijk/usb/issues/7" target="_blank">https://github.com/basvandijk/usb/issues/7</a><br>
</blockquote></div><br></div></div>