apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Collins-Sussman <suss...@collab.net>
Subject Re: apr_generate_random_bytes() blocks forever
Date Wed, 12 Mar 2003 15:59:57 GMT
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.



Mime
View raw message