<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 11, 2014 at 1:07 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">Thanks for your quick reply!<br>
<span class=""><br>
<br>
Andreas Voellmy <<a href="mailto:andreas.voellmy@gmail.com">andreas.voellmy@gmail.com</a>> writes:<br>
<br>
> On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari <<a href="mailto:bgamari.foss@gmail.com">bgamari.foss@gmail.com</a>> wrote:<br>
>><br>
</span><span class="">>> 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.<br>
><br>
><br>
> It added some complexity to the IO manager, but that should not affect<br>
> clients except those using the internal interface.<br>
><br>
</span>What I'm wondering is what the extra complexity bought us. It seems like<br>
the same thing could have been achieved with less breakage by making<br>
this per-fd instead of per-manager. I may be missing something, however.<br>
<span class=""><br></span></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
>> Going forward library authors now need<br>
>> to worry about whether the system event manager is one-shot or not.<br>
><br>
><br>
> Yes, but only library authors using the internal interface.<br>
><br>
><br>
>> 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.<br>
><br>
><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>
>><br>
> The system event manager is configured by GHC.Thread using ONE_SHOT if the<br>
> system supports it.<br>
><br>
> You can always create your own EventManager using GHC.Event.Manager.new or<br>
> GHC.Event.Manager.newWith functions. Those functions take a Bool argument<br>
> that control whether ONE_SHOT is used by the Manager returned by that<br>
> function (False means not to use ONE_SHOT). Would this work for usb?<br>
><br>
</span>I had considered this but looked for other options for two reasons,<br>
<br>
 * `loop` isn't exported by GHC.Event<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 * there is already a perfectly usable event loop thread in existence<br>
<br>
I'm a bit curious to know what advantages ONE_SHOT being per-manager<br>
carries over per-fd. If the advantages are large enough then we can just<br>
export `loop` and be done with it but the design as it stands strikes me<br>
as a bit odd.<br></blockquote><div><br></div><div>I suspect that a per-FD design would perform just as well, but I need to look at the details to be sure.</div><div><br></div><div><br></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>
</blockquote></div><br></div></div>