RE: Allocation of read buffers (was Re: svn commit: r1535686 - in /subversion/branches/log-addressing/subversion: include/svn_error_codes.h libsvn_fs_fs/transaction.c tests/libsvn_fs_fs/ tests/libsvn_fs_fs/fs-fs-pack-test.c)
From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 23 Apr 2014 12:50:38 +0200
On Windows the default stacksize is 1 MB, and as we are in many cases ‘just a library’ we should try to be a bit on the safe side, especially when we call into other code -or are likely to be called from other code- that might have their own buffers.
Until recently these buffers weren’t that big… Now that they are on trunk we should probably move them to a short lived scratch pool… or reduce them back to their original size.
From: Stefan Fuhrmann [mailto:stefan.fuhrmann_at_wandisco.com]
On Mon, Apr 21, 2014 at 7:05 PM, Ivan Zhakov <ivan_at_visualsvn.com <mailto:ivan_at_visualsvn.com> > wrote:
It's good time to make consistent in either way.
I agree that consistency is a goal in itself since it
That does not mean it would trump other goals, but
Where temporary read buffers should be allocated: on stack or in heap
I'd love to see them all allocated on stack but there
3 of these buffers at a time which translates to ~200k
stack memory. You can't do that too often in a 1M
stack that is the default in VisualStudio, IIRC.
Since it is conceivable that we would like to increase
So, +1 on allocation in pools. Exceptions should not
This is an archived mail posted to the Subversion Dev mailing list.