[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Ben Leslie benno at benno.id.au
Thu Jun 9 13:57:58 EDT 2016


On 9 June 2016 at 13:29, Steven D'Aprano <steve at pearwood.info> wrote:
> On Thu, Jun 09, 2016 at 12:54:31PM -0400, Ben Leslie wrote:
>
>> I think an exception is much easier for a user to deal with from a
>> practical point of view. Trying to work out why a process has hung is
>> obviously possible, but not necessarily easy.
>>
>> Having a process crash due to an exception is very easy to diagnose by
>> comparison.
>
> That only makes sense if the application is going to block for (say)
> five or ten minutes. If it's going to block for three seconds, you might
> not even notice. At least not on a server.
>
> But what are you going to do when you catch that exception?
>
> - Sleep for a few seconds, and try again? That's just blocking.
>
> - Stop waiting on secure randomness, and use something low quality
>   and insecure? That's how you get exploits.
>
> - Crash?

What does a program do when on any exception? It really depends on the
program and the circumstances in which it is running.

But I would think that in most circumstances 'crash' is the answer.

In the circumstances where this is most likely going to occur (server
startup) you are almost certainly going to have some type of
supervisory program restarting the failed process. It will almost
certainly be logging the failure. Having logs filled with process
restarts due to this error until there is finally entropy is better
than it just hanging. At least that is what I'd prefer to diagnose.

I think the real solution here would be outside of Python; starting a
process that needs entropy when the system isn't ready yet is just as
silly as running a 'mount' on a disk where the driver is still
loading, or 'ifconfig' on a network interface where the network driver
isn't yet loaded. But that isn't really a problem that can be solved
in the context of Python.

Cheers,

Ben


More information about the Python-Dev mailing list