<div dir="ltr">Another way to fix usb would be to re-register the callback after a previously registered callback is fired. Of course it is cheaper not to have to re-register, but re-registration in the latest IO manager should be fairly cheap, so this may not be a performance problem for usb. Would this work for you?<div><br></div><div>You could also use a CPP directive to only do this for GHC 7.8 and up.</div><div><br></div><div>If we want to allow usb to work unchanged, then we will have to revert to the non-ONE_SHOT behavior of registerFd and add some things to the API to allow GHC.Thread to register with ONE_SHOT behavior. Reverting could break clients of this semi-public API who have adapted to the 7.8 behavior.  There probably aren't of these clients other than GHC.Thread, so this may not be a big issue.</div><div><br></div><div>To do per-FD setting of ONE_SHOT or not, we actually need to have per-subscription settings, since there can be multiple invocations to register callbacks for a single file descriptor (e.g. from two different threads) and they might want different settings. If all the clients want ONE_SHOT we use ONE_SHOT registration, if all want persistent registrations we don't use ONE_SHOT. If it is mixed, then the manager has to choose one or the other and simulate the required behavior for the other registrations (e.g. choose persistent and automatically unregister for ONE_SHOT registrations). We could either always make the same choice (e.g. if there is a mix, use persistent), or we could have per-FD setting that is configurable by clients. </div><div><br></div><div>Andi</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 11, 2014 at 9:31 AM, Andreas Voellmy <span dir="ltr"><<a href="mailto:andreas.voellmy@gmail.com" target="_blank">andreas.voellmy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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><br>
<br>
Andreas Voellmy <<a href="mailto:andreas.voellmy@gmail.com" target="_blank">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" target="_blank">bgamari.foss@gmail.com</a>> wrote:<br>
>><br>
</span><span>>> 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><br></span></blockquote><div><br></div></span><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><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
><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></span><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><span class=""><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></span><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>
</blockquote></div><br></div>