<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 August 2016 at 14:22, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@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"><div class="gmail_extra"><span class=""><div class="gmail_quote">On 8 August 2016 at 13:32, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span></span>The
 Fedora Rawhide experiment I'm proposing in that email to the Fedora 
Python list should give us the data we (Fedora) need to decide whether or not 
this is one of those cases where it makes sense for us to carry a patch -
 if we get zero hits from the exception in ABRT, then it means the 
default blocking behaviour should be relatively safe (since people won't
 be encountering it), so we can drop the patch before the F26 Beta 
release, and Guido will have a solid data point backing up his design 
instincts. If we *do* get hits on the exception, then exactly what we do
 will depend on the nature of those hits, and in particular whether or 
not the change is helping folks find misconfigured Fedora environments 
they hadn't previously noticed, or if they're spurious notifications in situations where just blocking for a few hundred milliseconds would have resolved the problem on its own (as tested by inserting a "python -c 'import os; os.getrandom(1)" before whatever application startup is triggering the new exception).</div></div></div></blockquote><div><br></div></div></span>I started thinking a bit more about the outcomes we'd be looking for from such an experiment [1], and that reminded of the fact we could potentially do that with a much lower level of divergence if the upstream implementation issued a runtime warning when it needed to fall back to blocking behaviour. That is, rather that just calling "getrandom(size, 0)" unconditionally, the current logic for trying "getrandom(size, GRND_NONBLOCK)" first could be kept, and only the fallback to reading from "/dev/random/" changed to instead call "getrandom(size, 0)" with a preceding call to PyErr_Warn.<br></div></div></blockquote><div><br></div></div>Sorry, unhelpful typo there: the fallback is to "/dev/urandom", I just mistyped it and missed the error on proofreading.<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>