You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/02/16 22:05:50 UTC
Re: subversion _really_ slow
[Developers, this is regarding the client's tendency to wait for a
long time on systems where APR is configured to use /dev/random
instead of /dev/urandom, but there isn't enough random data for what
Subversion requests at a given moment.]
Pete Gonzalez <pg...@bluel.com> writes:
> At 01:02 PM 2/16/2005, kfogel@collab.net wrote:
> >But, what if Subversion is sharing APR with other applications? Can
> >Subversion just do whatever it wants with APR configuration?
> >Sometimes Subversion is linking against an existing APR, not building
> >its own.
> >(Of course, we could at least change our install instructions to
> >stipulate that if one *is* building APR just for Subversion, one
> >should configure with "--with-devrandom=/dev/urandom".)
>
> This is an interesting point. IMO the ideal solution would be to
> convince the APR people to fix their library, but if memory serves,
> the problem is from apr_generate_random_bytes() and only affects
> Subversion via the getuuid.c file. If you look at the source code,
> writing a custom replacement for apr_uuid_get() is trivially easy and
> you could probably improve the implementation.
Or we could finally become multi-threaded, and spawn one thread to get
the random bytes from APR, while another one tries the custom
implementation if the first takes too long...
Mostly kidding there, but yes, you have a point :-).
Developers, would we want a patch as suggested by Pete Gonzalez above?
I'm inclined to say "yes", but would like others' thoughts.
The problem is real. I've frustratingly experienced this lockup
myself, in fact.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion _really_ slow
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Note that we wouldn't actually be using the new API; apr would be using
> it internally in apr_uuid_get().
>
> > * In the meantime
>
> As we've done nothing about this problem for years, I don't see why it
> has suddenly become so urgent as to require difficult hacks to our
> source code while we wait for an apr fix.
Heh. Well, if the hacks really are difficult, then it's not worth it.
If they are not difficult, then it is as worth it as it has ever been
(much the same could be said for many other bugs, after all).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion _really_ slow
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-02-16 at 23:41, kfogel@collab.net wrote:
> * Try to get the new api into APR, which we may be able to do
> without too much trouble.
Note that we wouldn't actually be using the new API; apr would be using
it internally in apr_uuid_get().
> * In the meantime
As we've done nothing about this problem for years, I don't see why it
has suddenly become so urgent as to require difficult hacks to our
source code while we wait for an apr fix.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion _really_ slow
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> On Wed, 2005-02-16 at 17:05, kfogel@collab.net wrote:
> > > This is an interesting point. IMO the ideal solution would be to
> > > convince the APR people to fix their library, but if memory serves,
> > > the problem is from apr_generate_random_bytes() and only affects
> > > Subversion via the getuuid.c file. If you look at the source code,
> > > writing a custom replacement for apr_uuid_get() is trivially easy and
> > > you could probably improve the implementation.
>
> > Developers, would we want a patch as suggested by Pete Gonzalez above?
> > I'm inclined to say "yes", but would like others' thoughts.
>
> The right answer is for APR to rev apr_generate_random_bytes() to take a
> flag saying whether PRNG data is okay, and for apr_uuid_get() to say
> that PRNG data is okay. (If the system has no /dev/random, the flag
> shouldn't have any effect, in my opinion.) I don't see any reason to
> address this problem within the Subversion code base, since I think it
> wouldn't be as easy.
I think you're right in the long run. But the best strategy is
probably:
* Try to get the new api into APR, which we may be able to do
without too much trouble.
* In the meantime, add some substitute functionality to Subversion,
to use if that new APR symbol isn't defined. That way we
wouldn't require a bleeding edge APR to have this bug fixed right
now, but we wouldn't have to forever keep code in Subversion that
really belongs in APR.
I don't right now have time to *actually* do these things, but if we
are okay with this strategy, I could formally propose the APIs and
describe the implementations and at least (sigh) file an issue so we
don't forget.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion _really_ slow
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-02-16 at 17:05, kfogel@collab.net wrote:
> > This is an interesting point. IMO the ideal solution would be to
> > convince the APR people to fix their library, but if memory serves,
> > the problem is from apr_generate_random_bytes() and only affects
> > Subversion via the getuuid.c file. If you look at the source code,
> > writing a custom replacement for apr_uuid_get() is trivially easy and
> > you could probably improve the implementation.
> Developers, would we want a patch as suggested by Pete Gonzalez above?
> I'm inclined to say "yes", but would like others' thoughts.
The right answer is for APR to rev apr_generate_random_bytes() to take a
flag saying whether PRNG data is okay, and for apr_uuid_get() to say
that PRNG data is okay. (If the system has no /dev/random, the flag
shouldn't have any effect, in my opinion.) I don't see any reason to
address this problem within the Subversion code base, since I think it
wouldn't be as easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org