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

Re: Memory leak with 1.6.x clients

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 9 Jun 2009 10:52:19 -0400

On Tue, Jun 2, 2009 at 6:30 AM, Stefan Sperling<stsp_at_elego.de> wrote:
> On Mon, Jun 01, 2009 at 10:03:06PM +0200, Branko Čibej wrote:
>> Paul Burba wrote:
>> > You also brought up the question of whether we can change
>> > svn_io_open_uniquely_named()'s behavior from that currently described
>> > by its doc string without revving the API.  I tend to think not, the
>> > doc string is quite explicit in spelling out what the temp file's
>> > names will be...though maybe the language "with a unique name
>> > ***based*** on * utf-8 encoded @a filename" gives us some wiggle room,
>> > depending on how we interpret "based on".
>> >
>>
>> I think we would really, really be in need of psychiatric help if we
>> constrained ourselves to the predictability of temp file names based on
>> some docstring wording. Is anyone of the opinioin that the names of
>> temporary files are any kind of external API?
>
> No, but I don't think that matters here.
> As I said in another mail, I think the predictable tempfile names
> are still useful for tempfiles that users interact with, like log messages.
>
> So I'd say we need both random names (for security and performance)
> and predictable names (for user-friendliness) and make use of them
> appropriately.
>
> Stefan

Regardless of what we do with apr_file_mktemp() my more targeted fix,
http://subversion.tigris.org/ds/viewMessage.do?dsMessageId=2357582&dsForumId=462,
solves the performance problem regarding commits today. Committed
that change, with Mike's suggested tweaks, in r37972. I'll also
nominate it for backport to 1.6.x.

Paul

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360652
Received on 2009-06-09 16:52:40 CEST

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.