Joe Orton <joe@manyfish.co.uk> writes:
> > apr_generate_random_bytes(buf, length, dont_block);
> >
> > On systems where blocking is not a problem, the `dont_block' parameter
> > would simply have no effect. But the question is, are there systems
> > where blocking is a problem, but there's nothing we can do about it?
> > If so, dont_block would be a lie on such systems, unless we fell back
> > to some *really* unreliable method like pointer values XOR time of
> > day...
> >
> > I don't know if there are such systems, though. Anyone?
>
> When EGD is used as the source of random data, it may block when it runs
> out of entropy, and has no interface to provide lower-quality randomness
> like /dev/urandom.
>
> I think the flag must express a preference not a requirement, i.e.
> "prefer speed over quality".
I think it's important that APR have a way of providing random data
with a *guarantee* of non-blockage, not a preference.
If Solaris has a blocking EGD device and nothing else, then we need to
have a 'fallback' non-blocking code path which does lame things with
pointers/times/etc, like Karl suggests.
|