'apr_pstrdup' can be (if not already done by the compiler...) speed up a
little by inlining the call to 'apr_pmemdup'.
This avoid the overhead of calling a function and remove a redundant NULL
A proposed, untested, patch is attached.
begin 666 diff_apr2.patch
the function apr_array_cat could be speed up a bit by resetting only the
memory that need to be.
Actually, when there is not enough space in the destination table we do :
- allocate new memory and set it all to 0
- copy the dst table to the new location
- copy the src table after
I'm currently trying to reduce httpd memory footprint.
On my test machine, processing a request requires about 15ko in the
'request' pool. I'm trying to reduce it to only use 8k which is the
minimum allocated on Linux
Must be related to:
https://twitter.com/infrabot (see post around the date in the first
There were about 9M mails to process!
It was expected to take some times to recover.
Le 15/05/2014 14:55, Jeff Trawick a écrit :
here is a patch against APR in order to fix most of the doxygen warnings.
Note that I have updated a function prototype in apr_md5.h in order to
match the corresponding function in apr_md5.c. s/password/pw/
I have also turned some @tip into @note because @tip is not a known
I would like to have details about the way patches should be submitted
and backported within APR.
The process seems to be different than the one from httpd.
In http://apr.apache.org/guidelines.html, it is stated that changes do
not require review and that only the bigger ones are (only)
any plan/interrest in having apr_crypto_memzero() available even if
APU_HAVE_CRYPTO is not defined?
There are a few places in httpd and in APR that should use this safer
Le 28/05/2018 à 21:45, jaillet...@apache.org a écrit :
Date: Mon May 28 19:45:56
I was looking for such info and didn't found.
Why so much chars left for params split? Should I fire a request or
this will not be changed in future by concept?
On 20.08.2018 22:14, Christophe JAILLET wrote:
This seems to be mysql APR driver specific.
For some reasons, in APR, i
Le 25/08/2018 à 20:18, Yann Ylavic a écrit :
On Sat, Aug 25, 2018 at 3:28 PM wrote:
--- apr/apr/branches/1.7.x/misc/win32/start.c (original)
+++ apr/apr/branches/1.7.x/misc/win32/start.c Sat Aug 25 13:28:30 2018
@@ -39,7 +39,7 @@ int APR_DECLARE_DATA apr_app_init_comple
* _CRT_BLOCK to
I got twice this kind of messages after commit that should be doxygen
Is it expected or do I do something wrong?
Le 26/08/2018 à 13:59, build...@apache.org a écrit :
The Buildbot has detected a new failure on builder apr-x64-macosx-trunk while
building . Full details are
Le 31/08/2018 à 16:17, Eric Covener a écrit :
On Fri, Aug 31, 2018 at 10:04 AM Yann Ylavic wrote:
On Fri, Aug 31, 2018 at 3:29 PM William A Rowe Jr wrote:
I presume you are subscribed to the commits list, which broadcasts our CI
Hmm, I'm supposed to be subscribed to commits@ list
Le 10/09/2018 à 23:22, William A Rowe Jr a écrit :
Please cast your votes on the following release candidate
found at http://apr.apache.org/dev/dist/ (note release.sh
is generating sha256+sha512, all in coreutils format.)
[ ] +/-1
This vote will conclude at 5pm EDT
Mail list logo