apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: apr_generate_random_bytes() blocks forever
Date Wed, 16 Apr 2003 09:50:17 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.

Why? Please provide some cases that aren't SVN specific...

> > 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.

Are you sure? Once more it's altering apr to accomodate SVN. APR should do
the right thing in all situations. APR is a general purpose library, not a
place to add svn specific functionality.

> > 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.

Well, if you want randomness you want randomness. If you want psuedo-random
bytes that don't block that's what you want. I don't see how changing our
randomness to simply not block is the right thing. Also passing in flags
doesn't strike me as being a clever thing to do.

"...using APR I called the random function with a non-blocking flag and it
gave me shit..."

That sort of comment would become a reality and simply saying "it's in the
documentation" doesn't really solve it for me. If you really want something
like this then you need to add a new api that differentiates between what
you want and the randomness that we strove so hard to provide.

david


Mime
View raw message