Joe Orton <[EMAIL PROTECTED]> 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.
