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 Tue, 15 Apr 2003 14:00:30 GMT
"David Reid" <dreid@jetnet.co.uk> writes:

> Ben's point is more (I think) that if we say we're providing randomness then
> we should provide that.

But a caller isn't allowed to *explicitly* ask for poor-quality,
non-blocking randomness?  Why not?   If the word "randomness" bothers
people, then let's create a new function that never uses the word:
apr_generate_bits_nonblocking() or something.

Nobody is arguing that we shouldn't have a function that produces
high-quality randomness.  Most of the time, that's what people want.
But we *also* need the ability to produce very poor randomness which
doesn't ever block for entropy.

> Bear in mind that APR could be used for a lot of
> things, and having a potentially very weak random function isn't going to
> cut it in a lot of places.

I'm not advocating a weak random function.  I'm advocating either one
function with a 'strong/weak' boolean flag, or two separate functions,
one for strong/blocking, one for weak/non-blocking.

Subversion, right now, needs to generate some poor-quality
pseudorandom bits, and it *cannot* block.  Yes, it's a bit unusual,
but not an outrageous request.

> FWIW I've seen the sort of api that Ben alludes to elsewhere and don't see a
> huge problem in using it. That said ben is the math's wunderkind for this
> stuff so perhaps he can provide an overview of what his proposed api would
> look like to allay fears.

He did give a very detailed overview of his proposed API, if you go
back read his original response.  The problem is that I haven't the
first idea of how to start implementing it.  And his API seems to
focus on passing parameters that tweak the quality of the randomness,
but for Subversion, what really matters in the non-blocking aspect.

View raw message