[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: subversion _really_ slow

From: <kfogel_at_collab.net>
Date: 2005-02-16 23:05:50 CET

[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 <pgonzalez@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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 16 23:24:10 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.