Commits on Oct 6, 2020

1. Defer IDGenerator initialization until first use …

   Initializing the `IDGenerator` from `init()` means that any downstream
   project which transitively imports this package somewhere in its
   dependency tree will incur `getrandom()` syscalls it has no control over
   at startup.
   
   This causes problems for us in
   [Ignition](https://github.com/coreos/ignition), where we're transitively
   pulling in this package via cloud.google.com/go/storage. Ignition runs
   very early during the boot process, which means that even though this
   isn't using `GRND_RANDOM`, the `getrandom` syscall can block until the
   entropy pool is ready. This is a real problem when running in VMs on
   systems which don't provide a virtualized RNG device (such as VMware) or
   which lack RDRAND.
   
   I can't find a good reference for this, but I think in general it should
   be considered good practice to avoid I/O like this in `init()` in favour
   of a more lazy approach (or an explicit `Initialize()` function for
   clients to call).
   
   Otherwise, *every* program which pulls in the package will pay for it,
   whether or not they intend to actually make use of the functionality
   those syscalls are priming. (While it's not relevant here, another
   advantage of not using `init()` for this is that I/O is fallible, and
   `init()` semantics means errors can't be handled sanely.)
   
   Let's rework things here so that we don't actually initialize the
   `IDGenerator` fields until the first time it's used.

   

   jlebon committed Oct 6, 2020
   Copy the full SHA

   b45df3d View commit details

   Browse the repository at this point in the history