[m-rev.] for comment / review: system random number generator
novalazy at gmail.com
Thu Jan 28 11:16:50 AEDT 2021
On Wed, 27 Jan 2021 16:42:38 +1100 Julien Fischer <jfischer at opturion.com> wrote:
> The diff below is a proposed interface for the system random number generator.
> I would like feedback on its design in general, as well as the names of various
> The diff includes implementations for the C# and Java backends; support for the
> C backends is NYI, but the plan is as follows:
> Windows - rand_s()
> macOS, *BSD - arc4random() and friends
> Linux - getrandom() for kernels / c libs that support it
> - read from /dev/urandom otherwise
> Other Unix - read from /dev/urandom or /dev/random
> as appropriate, or simply not supported.
> My plan is to commit this diff after review and the add the implementations for
> the various C platforms separately. Until the C implementations are complete,
> the new submodule will not be included in the public library documentation.
> + % A handle through which the system RNG can be accessed.
> + %
> + % In general, it is *not* safe to share system RNG handles across
> + % multiple threads. In circumstances where multiple threads require access
> + % to the system RNG, each thread should open its own handle.
> + %
> +:- type system_rng.
Which implementation might this warning apply to?
In low-level C .par grades, "threads" might refer to Mercury threads
that can be moved across OS threads. I could see that being a problem
if the system RNG has state associated with an OS thread.
> +do_open_system_rng(_, _, _, _, _) :-
> + private_builtin.sorry("No system RNG available").
This should return an error.
The design looks fine to me.
More information about the reviews