Re: Hard coded time value in apr_memcache.c

2023-05-10 Thread Christophe JAILLET 

Le 10/05/2023 à 17:20, Ruediger Pluem a écrit :

I am a little bit bothered by the following hardcoded time in 
memcache/apr_memcache.c::apr_memcache_find_server_hash_default

 if (curtime - ms->btime >  apr_time_from_sec(5)) {
 ms->btime = curtime;
 if (mc_version_ping(ms) == APR_SUCCESS) {
 make_server_live(mc, ms);
#if APR_HAS_THREADS
 apr_thread_mutex_unlock(ms->lock);
#endif
 break;
 }
 }

I want to make this configurable. I can think of the following three options:

1. Create an apr_memcache_create_ex that allows to set this value.
2. Create a new setter / getter function to allow to set / get this for a 
previously created apr_memcache_t.
3. Encourage people to directly change the field that holds the time 
information in the public struct apr_memcache_t for
a previously created apr_memcache_t.

What makes most sense from an API point of view?

Regards

Rüdiger




Hi,

personally, I think that 2. is the cleaner way to go.

CJ

Re: svn commit: r1909176 - in /apr/site/trunk/xdocs: download.xml index.xml

2023-04-17 Thread Christophe JAILLET 

Le 16/04/2023 à 16:35, cove...@apache.org a écrit :

Author: covener
Date: Sun Apr 16 14:35:27 2023
New Revision: 1909176

URL: http://svn.apache.org/viewvc?rev=1909176&view=rev
Log:
publishing release apr-1.7.4

Modified:
 apr/site/trunk/xdocs/download.xml
 apr/site/trunk/xdocs/index.xml

Modified: apr/site/trunk/xdocs/download.xml
URL: 
http://svn.apache.org/viewvc/apr/site/trunk/xdocs/download.xml?rev=1909176&r1=1909175&r2=1909176&view=diff
==
--- apr/site/trunk/xdocs/download.xml (original)
+++ apr/site/trunk/xdocs/download.xml Sun Apr 16 14:35:27 2023
@@ -50,28 +50,28 @@ list of mirrors.
  
  
  
-APR 1.7.3 is the best available version

+APR 1.7.4 is the best available version
  
  APR is the base portability library.
  
  
  
  Unix Source:

-apr-1.7.3.tar.gz
-[https://www.apache.org/dist/apr/apr-1.7.3.tar.gz.asc";>PGP]
-[https://www.apache.org/dist/apr/apr-1.7.3.tar.gz.sha256";>SHA256]
+apr-1.7.4.tar.gz
+[https://www.apache.org/dist/apr/apr-1.7.4.tar.gz.asc";>PGP]
+[https://www.apache.org/dist/apr/apr-1.7.4.tar.gz.sha256";>SHA256]
  
  
  Unix Source:

-apr-1.7.3.tar.bz2
-[https://www.apache.org/dist/apr/apr-1.7.3.tar.bz2.asc";>PGP]
-[https://www.apache.org/dist/apr/apr-1.7.3.tar.bz2.sha256";>SHA256]
+apr-1.7.4.tar.bz2
+[https://www.apache.org/dist/apr/apr-1.7.4.tar.bz2.asc";>PGP]
+[https://www.apache.org/dist/apr/apr-1.7.4.tar.bz2.sha256";>SHA256]
  
  
  Win32 Source:

-apr-1.7.3-win32-src.zip
-[https://www.apache.org/dist/apr/apr-1.7.3-win32-src.zip.asc";>PGP]
-[https://www.apache.org/dist/apr/apr-1.7.3-win32-src.zip.sha256";>SHA256]
+apr-1.7.4-win32-src.zip
+[https://www.apache.org/dist/apr/apr-1.7.4-win32-src.zip.asc";>PGP]
+[https://www.apache.org/dist/apr/apr-1.7.4-win32-src.zip.sha256";>SHA256]
  
  
  Other files


Modified: apr/site/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewvc/apr/site/trunk/xdocs/index.xml?rev=1909176&r1=1909175&r2=1909176&view=diff
==
--- apr/site/trunk/xdocs/index.xml (original)
+++ apr/site/trunk/xdocs/index.xml Sun Apr 16 14:35:27 2023
@@ -24,7 +24,7 @@ or features.
  libraries are
  
  

-  APR 1.7.3, released February 1, 2023
+  APR 1.7.4, released April 16, 2023
APR-util 1.6.3, released February 1, 2023
APR-iconv 1.2.2, released October 22, 2017
  
@@ -32,7 +32,7 @@ libraries are
  
  
  

-Apache Portable Runtime 1.7.3 Released
+Apache Portable Runtime 1.7.4 Released
  
  

 The Apache Software Foundation and the Apache Portable Runtime





Hi,

I don't know if something went wrong or if more time is needed, but 
theses changes are not yet visible on:

   https://apr.apache.org/

CJ

Re: [VOTE] Release apr-1.7.4-rc1 as apr-1.7.4

2023-04-15 Thread Christophe JAILLET 

Le 13/04/2023 à 04:25, Eric Covener a écrit :

Hi all,

Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/apr/

I would like to call a VOTE over the next few days to release
this candidate tarball apr-1.7.4-rc1 as 1.7.4:
[X] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:


The SVN candidate source is found at tags/1.7.4-rc1-candidate.



+1

Tested on:
  Linux pop-os 6.2.0-76060200-generic
  gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0

CJ

Re: svn commit: r1909094 - in /apr/apr/branches/1.8.x: ./ CHANGES

2023-04-12 Thread Christophe JAILLET 

Le 12/04/2023 à 20:13, Evgeny Kotkov via dev a écrit :

Christophe JAILLET  writes:


If we remove things that are part of previous 1.7.x releases, shouldn't
Changes for APR 1.7.[23] be added here instead?


Hm, since these are the 1.8.x CHANGES maybe it'd be better to drop the 1.7.1,
1.7.2 and 1.7.3 entries from here and just link to branches/1.7.x/CHANGES,
to avoid maintaining two separate copies of 1.7.x CHANGES.

How does that sound?


+1 for me.

Looking at 1.7 and 1.6 it seems it was done this way in previous releases.

CJ




Thanks,
Evgeny Kotkov

Re: svn commit: r1909094 - in /apr/apr/branches/1.8.x: ./ CHANGES

2023-04-12 Thread Christophe JAILLET 

Le 12/04/2023 à 15:34, kot...@apache.org a écrit :

Author: kotkov
Date: Wed Apr 12 13:34:56 2023
New Revision: 1909094

URL: http://svn.apache.org/viewvc?rev=1909094&view=rev
Log:
On 1.8.x branch: Merge r1909090 from trunk:

   CHANGES: Remove entries that were released in APR 1.7.3.

Modified:
 apr/apr/branches/1.8.x/   (props changed)
 apr/apr/branches/1.8.x/CHANGES

Propchange: apr/apr/branches/1.8.x/
--
   Merged /apr/apr/trunk:r1909090

Modified: apr/apr/branches/1.8.x/CHANGES
URL: 
http://svn.apache.org/viewvc/apr/apr/branches/1.8.x/CHANGES?rev=1909094&r1=1909093&r2=1909094&view=diff
==
--- apr/apr/branches/1.8.x/CHANGES [utf-8] (original)
+++ apr/apr/branches/1.8.x/CHANGES [utf-8] Wed Apr 12 13:34:56 2023
@@ -15,19 +15,6 @@ Changes for APR 1.8.0
  
*) Fix double free on exit when apr_app is used on Windows. [Ivan Zhakov]
  
-  *) Fix a deadlock when writing to locked files opened with APR_FOPEN_APPEND

- on Windows. PR 50058.
- [Evgeny Kotkov ]
-
-  *) apr_file_gets: Optimize for buffered files on Windows.
- [Evgeny Kotkov ]
-
-  *) apr_file_write: Optimize large writes to buffered files on Windows.
- [Evgeny Kotkov ]
-
-  *) apr_file_read: Optimize large reads from buffered files on Windows.
- [Evgeny Kotkov]
-
  Changes for APR 1.7.1


Hi,

If we remove things that are part of previous 1.7.x releases, shouldn't 
Changes for APR 1.7.[23] be added here instead?


CJ

  
*) SECURITY: CVE-2021-35940 (cve.mitre.org)

Re: svn commit: r1907634 - /apr/apr/trunk/include/apr_buckets.h

2023-02-14 Thread Christophe JAILLET 

Le 14/02/2023 à 11:51, Ivan Zhakov via dev a écrit :
On Tue, 14 Feb 2023 at 10:58, > wrote:


Author: jailletc36
Date: Tue Feb 14 07:56:50 2023
New Revision: 1907634

URL: http://svn.apache.org/viewvc?rev=1907634&view=rev

Log:
Re-order the fields of 'struct apr_bucket_file' to avoid a hole and
some padding.

Before the patch, pahole states that:

struct apr_bucket_file {
         apr_bucket_refcount        refcount;             /*     0 
    4 */


         /* XXX 4 bytes hole, try to pack */

         apr_file_t *               fd;                   /*     8 
    8 */
         apr_pool_t *               readpool;             /*    16 
    8 */
         int                        can_mmap;             /*    24 
    4 */


         /* XXX 4 bytes hole, try to pack */

         apr_size_t                 read_size;            /*    32 
    8 */


         /* size: 40, cachelines: 1, members: 5 */
         /* sum members: 32, holes: 2, sum holes: 8 */
         /* last cacheline: 40 bytes */
};

Nice, but I'd like to note that this change breaks ABI and can be 
released only in APR 2.0.




Sure.

I was just wondering if such small optimizations make sense or not.
It potentially makes backport of some other patches more difficult and 
breaks ABI.


So, does it worth the effort?

I've spotted a few of them in APR, and would make sure that such patches 
are welcomed before committing other things.


CJ




--
Ivan Zhakov

Re: svn commit: r1902219 - in /apr/apr/branches/1.8.x: ./ test/testlock.c

2022-06-25 Thread Christophe JAILLET 

Le 24/06/2022 à 11:06, yla...@apache.org a écrit :

Author: ylavic
Date: Fri Jun 24 09:06:05 2022
New Revision: 1902219

URL: http://svn.apache.org/viewvc?rev=1902219&view=rev
Log:
test/testlock: Fix -Werror=return-type

* test/testlock.c(thread_mutex_function,
   thread_mutex_sleep_function):
   Thread (APR_THREAD_FUNC) functions should return a pointer (NULL).


Merge r1902181 from trunk.
Submitted by: ylavic

Modified:
 apr/apr/branches/1.8.x/   (props changed)
 apr/apr/branches/1.8.x/test/testlock.c

Propchange: apr/apr/branches/1.8.x/
--
   Merged /apr/apr/trunk:r1902181

Modified: apr/apr/branches/1.8.x/test/testlock.c
URL: 
http://svn.apache.org/viewvc/apr/apr/branches/1.8.x/test/testlock.c?rev=1902219&r1=1902218&r2=1902219&view=diff
==
--- apr/apr/branches/1.8.x/test/testlock.c (original)
+++ apr/apr/branches/1.8.x/test/testlock.c Fri Jun 24 09:06:05 2022
@@ -111,6 +111,7 @@ static void *APR_THREAD_FUNC thread_mute
  break;
  }
  return NULL;
+return NULL;


???


  }
  
  /* Sleepy-loop until f_ value matches val: */

@@ -139,6 +140,7 @@ static void *APR_THREAD_FUNC thread_mute
  rv = apr_thread_mutex_unlock(timeout_mutex);
  
  apr_thread_exit(thd, APR_SUCCESS);

+return NULL;
  }
  
  static void *APR_THREAD_FUNC thread_cond_producer(apr_thread_t *thd, void *data)

Re: [VOTE] apr-1.6.5 release

2018-09-11 Thread Christophe JAILLET 

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.)

Release apr-1.6.5
  [  ] +/-1

This vote will conclude at 5pm EDT Thursday 9/13, for
announcement Friday in the event of a successful vote.


+1, Ubuntu 18.04, gcc 8.1.0

CJ

Re: svn commit: r1839755 - in /apr/apr/trunk: include/apr_json.h json/apr_json.c json/apr_json_decode.c

2018-08-31 Thread Christophe JAILLET 

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 
results?

Hmm, I'm supposed to be subscribed to commits@ list but somehow I
didn't receive this one (yet?).
Or is it a special list?

I don't get it either!


Same here, I've never seen such CI mail.

Could you give details of what is it, and maybe update 
https://apr.apache.org/mailing-lists.html?


CJ

Re: buildbot failure in on apr-x64-macosx-trunk

2018-08-26 Thread Christophe JAILLET 
I got twice this kind of messages after commit that should be doxygen 
only related.


Is it expected or do I do something wrong?

CJ

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 available at:
 https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/148

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: svn-x64-macosx-dgvrs

Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' triggered 
this build
Build Source Stamp: [branch apr/apr/trunk] 1839203
Blamelist: jailletc36

BUILD FAILED: failed Test

Sincerely,
  -The Buildbot

Re: svn commit: r1839047 - in /apr/apr/branches/1.7.x: ./ misc/win32/start.c

2018-08-25 Thread Christophe JAILLET 

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 trick the system into trusting our store.
   */
  static int warrsztoastr(const char * const * *retarr,
-const wchar_t * arrsz, int args)
+const wchar_t * arrsz)
  {
  const apr_wchar_t *wch;
  apr_size_t totlen;
@@ -50,11 +50,9 @@ static int warrsztoastr(const char * con
  char *strs;
  int arg;

-if (args < 0) {
-for (args = 1, wch = arrsz; wch[0] || wch[1]; ++wch)
-if (!*wch)
-++args;
-}
+for (args = 1, wch = arrsz; wch[0] || wch[1]; ++wch)
+if (!*wch)
+++args;
  wsize = 1 + wch - arrsz;

Hmm, does this compile (including in trunk)? I don't see where args is
declared now...

Regards,
Yann.


Hmmm, looks embarrassing.
Sorry for this obviously un-compiled and bogus commit.

I guess that we should have:
   int arg, args;

CJ

Re: Special characters in password for mod_dbd

2018-08-21 Thread Christophe JAILLET 

Hi,

I have no idea why so many separators have been allowed.
I googled a bit yesterday, and didn't find anything useful. Most other 
mysql connectors I've found only use ';'.


But it is documented this way since a long time in APR.

Removing some separators could break some existing configuration. So, 
IMHO, it is unlikely to be accepted.
We maybe should have some way to escape some characters to be allowed 
these delimiters to be used as "normal" characters.


I cross-post to APR dev@ mailing list to have others feed-back on it.

CJ

Le 21/08/2018 à 09:17, Mimiko a écrit :

Thank you

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, in function dbd_mysql_open(), fields are 
split according to delimiters in:

 static const char *const delims = " \r\n\t;|,";

See Remarks about MySQL at:
http://apr.apache.org/docs/apr-util/1.6/group___a_p_r___util___d_b_d.html#gabddb1fdcb2f8a5f5b83127485c78e8ae 




According to the code, there is no way to avoid the "incorrect" split 
of the DBDParams parameter.

I guess that your best option is to modify the password.

Re: svn commit: r1832415 - /apr/apr/trunk/crypto/apr_md4.c

2018-06-15 Thread Christophe JAILLET 

Hi,

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 
memset'ing.


CJ

Le 28/05/2018 à 21:45, jaillet...@apache.org a écrit :

Author: jailletc36
Date: Mon May 28 19:45:56 2018
New Revision: 1832415

URL: http://svn.apache.org/viewvc?rev=1832415&view=rev
Log:
Better stack memseting of sensitive information.

Why is 'apr_crypto_memzero()' only available if APU_HAVE_CRYPTO=1?

See PR 55738

Modified:
 apr/apr/trunk/crypto/apr_md4.c

Modified: apr/apr/trunk/crypto/apr_md4.c
URL: 
http://svn.apache.org/viewvc/apr/apr/trunk/crypto/apr_md4.c?rev=1832415&r1=1832414&r2=1832415&view=diff
==
--- apr/apr/trunk/crypto/apr_md4.c (original)
+++ apr/apr/trunk/crypto/apr_md4.c Mon May 28 19:45:56 2018
@@ -41,6 +41,7 @@
  #include "apr_strings.h"
  #include "apr_md4.h"
  #include "apr_lib.h"
+#include "apr_crypto.h" /* for apr_crypto_memzero, if available */
  
  #if APR_HAVE_STRING_H

  #include 
@@ -359,7 +360,11 @@ static void MD4Transform(apr_uint32_t st
  state[3] += d;
  
  /* Zeroize sensitive information. */

+#if APU_HAVE_CRYPTO
+apr_crypto_memzero(x, sizeof(x));
+#else
  memset(x, 0, sizeof(x));
+#endif
  }
  
  /* Encodes input (apr_uint32_t) into output (unsigned char). Assumes len is

Question about patches

2015-03-16 Thread Christophe JAILLET 

Hi,

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) encouraged 
to be reviewed.


In svn, we can find trunk, 1.6.x branch, 1.5.x branch...
Current release is 1.5.1

I assume that previous release (1.4.x...) are no more maintained


Which one(s) should be used for changes? The 3 of them (trunk, 1.6.x , 
1.5.x)?

What is the main difference between 1.6.x (not release yet) and trunk?
Does odd/even numbers have a special meaning as in httpd?

Thanks in advance.
CJ

Doxygen fixes

2014-07-19 Thread Christophe JAILLET 

Hi,
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 
keyword for doxygen.


Best regards,
CJ
Index: include/apr_dbd.h
===
--- include/apr_dbd.h   (révision 1611200)
+++ include/apr_dbd.h   (copie de travail)
@@ -231,7 +231,7 @@
  *  May be a no-op.
  *
  *  @param driver - the driver
- *  @param handle - the db connection
+ *  @param pool - working pool
  *  @param trans - the transaction.
  *  @return 0 for success or error code
  */
Index: include/apr_md5.h
===
--- include/apr_md5.h   (révision 1611200)
+++ include/apr_md5.h   (copie de travail)
@@ -131,17 +131,17 @@
 
 /**
  * Encode a password using an MD5 algorithm
- * @param password The password to encode
+ * @param pw The password to encode
  * @param salt The salt string to use for the encoding
  * @param result The string to store the encoded password in
  * @param nbytes The size of the result buffer
  */
-APR_DECLARE(apr_status_t) apr_md5_encode(const char *password, const char 
*salt,
+APR_DECLARE(apr_status_t) apr_md5_encode(const char *pw, const char *salt,
  char *result, apr_size_t nbytes);
 
 /**
  * Encode a password using the bcrypt algorithm
- * @param password The password to encode
+ * @param pw The password to encode
  * @param count The cost of the encoding, possible values are 4 to 31
  * @param salt Pointer to binary data to be used as salt for the encoding
  * @param salt_len The size of the salt data (must be >= 16)
Index: include/apr_memcache.h
===
--- include/apr_memcache.h  (révision 1611200)
+++ include/apr_memcache.h  (copie de travail)
@@ -370,7 +370,6 @@
  * @param msserver to query
  * @param p Pool to allocate answer from
  * @param baton location to store server version string
- * @param len   length of the server version string
  */
 APR_DECLARE(apr_status_t) apr_memcache_version(apr_memcache_server_t *ms,
apr_pool_t *p,
Index: include/apr_network_io.h
===
--- include/apr_network_io.h(révision 1611200)
+++ include/apr_network_io.h(copie de travail)
@@ -750,8 +750,10 @@
   apr_sockaddr_t *sockaddr);
 
 /**
- * Write the IP address (in numeric address string format) of the APR
- * socket address @a sockaddr into the buffer @a buf (of size @a buflen).
+ * Write the IP address (in numeric address string format) of an APR
+ * socket address.
+ * @param buf The buffer to write to.
+ * @param buflen The size of the buffer.
  * @param sockaddr The socket address to reference.
  */
 APR_DECLARE(apr_status_t) apr_sockaddr_ip_getbuf(char *buf, apr_size_t buflen,
Index: include/apr_pools.h
===
--- include/apr_pools.h (révision 1611200)
+++ include/apr_pools.h (copie de travail)
@@ -727,7 +727,7 @@
  * In this case the caller must call apr_pool_join() to indicate this
  * guarantee to the APR_POOL_DEBUG code.
  *
- * These functions are only implemented when #APR_POOL_DEBUG is set.
+ * These functions are only implemented when APR_POOL_DEBUG is set.
  *
  * @{
  */
Index: include/apr_thread_pool.h
===
--- include/apr_thread_pool.h   (révision 1611200)
+++ include/apr_thread_pool.h   (copie de travail)
@@ -267,7 +267,7 @@
 /**
  * Access function for the threshold of tasks in queue to trigger a new thread.
  * @param me The thread pool
- * @param cnt The new threshold
+ * @param val The new threshold
  * @return The original threshold
  */
 APR_DECLARE(apr_size_t) apr_thread_pool_threshold_set(apr_thread_pool_t *me,
Index: include/arch/win32/apr_arch_utf8.h
===
--- include/arch/win32/apr_arch_utf8.h  (révision 1611200)
+++ include/arch/win32/apr_arch_utf8.h  (copie de travail)
@@ -30,7 +30,7 @@
  * to the ucs-2 wide Unicode format.  This function is used for filename and 
  * other resource conversions for platforms providing native Unicode support.
  *
- * @tip Only the errors APR_EINVAL and APR_INCOMPLETE may occur, the former
+ * @note Only the errors APR_EINVAL and APR_INCOMPLETE may occur, the former
  * when the character code is invalid (in or out of context) and the later
  * when more characters were expected, but insufficient characters remain.
  */
@@ -44,7 +44,7 @@
  * the utf-8 octet-encoded Unicode.  This function is used for filename and 
  * other resource conversions for platforms providing nat

Re: my messages get queued

2014-05-17 Thread Christophe JAILLET 

Must be related to:

https://blogs.apache.org/infra/entry/mail_outage
https://twitter.com/infrabot (see post around the date in the first 
link)


There were about 9M mails to process!
It was expected to take some times to recover.

CJ


Le 15/05/2014 14:55, Jeff Trawick a écrit :
On Fri, May 9, 2014 at 2:46 PM, Helmut Tessarek > wrote:


Hello,

My messages get queued, but never really processed:

May  9 20:26:54 atvie01s sendmail[25243]: s49IQQtF025239:
to=mailto:dev@apr.apache.org>>,
delay=00:00:26, xdelay=00:00:26, mailer=esmtp,
pri=152179, relay=mx1.eu.apache.org .
[192.87.106.230 ], dsn=2.0.0, stat=Sent
(Queued! <536d1dd2.9030...@evermeet.cx
> (Queue-Id: DAD7981B542))

Any idea what is going on?


I haven't seen a notice of problems from infrastructure, but I have 
seen terrible mailing list delays over the last week.  For example, 
just now I saw a commit message from 8 days ago.  Normally I might see 
a delay of up to a few hours.


I don't know whether or not this addresses your exact problem.


Cheers,
 Helmut

--
regards Helmut K. C. Tessarek
lookup http://sks.pkqs.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/




--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/

Re: [PATCH] Reduce apr_[i|l|off_t_]toa memory footprint for common cases

2013-04-01 Thread Christophe JAILLET 

Le 28/03/2013 19:32, Jeff Trawick a écrit :

On Thu, Mar 28, 2013 at 1:38 PM, Stefan Fritsch  wrote:

On Monday 25 March 2013, Christophe JAILLET wrote:

As a first step, I noticed that apr_itoa, apr_ltoa, apr_off_t_toa
could  be tweaked to require less memory for some common cases.
The attached patch reduces memory use for small values, that is to
say  for strings that fit in 8 bytes (including NULL)

Looks like a reasonable optimization to me.

Cheers,
Stefan

When shrinking it down to 8, why not avoid the apr_palloc altogether?
Also, how about lower-casing the name BUFFER_SIZE since it isn't
const?



I'm not sure it is possible to avoid the call to apr_palloc.

For BUFFER_SIZE, I 100% agree with you. Previously it was a 'const int', 
and I just left it as it was.


There are also some tab vs space possible clean-up in these functions.

Finally, even if the 3 functions work the same way, they have different 
way to write it:

*--start = '0' + (n % 10);
*--start = (char)('0' + (n % 10));
*--start = '0' + (char)(n % 10);
The 2nd version is, IMO, the best one.

I didn't include it in my patch to reduce the differences.

CJ

[PATCH] Reduce apr_[i|l|off_t_]toa memory footprint for common cases

2013-03-25 Thread Christophe JAILLET 

Hi list,

I'm currently trying to reduce httpd memory footprint. 
(http://www.mail-archive.com/dev@httpd.apache.org/msg56558.html)


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 (min: 2 x 4ko pages)



As a first step, I noticed that apr_itoa, apr_ltoa, apr_off_t_toa could 
be tweaked to require less memory for some common cases.
The attached patch reduces memory use for small values, that is to say 
for strings that fit in 8 bytes (including NULL)



On my system:
apr_itoa allocates 14 (4*3+2) bytes, which gets rounded to 16. A common 
use is for HTTP status code which fits in much less.

--> 8 bytes can be saved in the request pool

apr_off_t_toa allocates 26 (8*3+2) bytes, which gets rounded to 32. A 
common use is for the length of the answer. Common pages are well under 
9.999.999 bytes.

--> 24 bytes can be saved in the request pool


This is not that much, but is a start.

Best regards,
CJ
Index: strings/apr_strings.c
===
--- strings/apr_strings.c   (révision 1460121)
+++ strings/apr_strings.c   (copie de travail)
@@ -359,10 +359,17 @@
 
 APR_DECLARE(char *) apr_itoa(apr_pool_t *p, int n)
 {
-const int BUFFER_SIZE = sizeof(int) * 3 + 2;
-char *buf = apr_palloc(p, BUFFER_SIZE);
-char *start = buf + BUFFER_SIZE - 1;
+int BUFFER_SIZE = sizeof(int) * 3 + 2;
+char *buf, *start;
 int negative;
+
+/* apr_palloc aligns memory on 8 bytes (see apr_general.h).
+ * So, for small values of 'n', do not over-allocate some memory. */
+if (sizeof(int) >= 4 && n<=999L && n>=-99L)
+BUFFER_SIZE = 8;
+
+buf = apr_palloc(p, BUFFER_SIZE);
+start = buf + BUFFER_SIZE - 1;
 if (n < 0) {
negative = 1;
n = -n;
@@ -383,10 +390,17 @@
 
 APR_DECLARE(char *) apr_ltoa(apr_pool_t *p, long n)
 {
-const int BUFFER_SIZE = sizeof(long) * 3 + 2;
-char *buf = apr_palloc(p, BUFFER_SIZE);
-char *start = buf + BUFFER_SIZE - 1;
+int BUFFER_SIZE = sizeof(long) * 3 + 2;
+char *buf, *start;
 int negative;
+
+/* apr_palloc aligns memory on 8 bytes (see apr_general.h).
+ * So, for small values of 'n', do not over-allocate some memory. */
+if (sizeof(long) >= 4 && n<=999L && n>=-99L)
+BUFFER_SIZE = 8;
+
+buf = apr_palloc(p, BUFFER_SIZE);
+start = buf + BUFFER_SIZE - 1;
 if (n < 0) {
negative = 1;
n = -n;
@@ -407,10 +421,17 @@
 
 APR_DECLARE(char *) apr_off_t_toa(apr_pool_t *p, apr_off_t n)
 {
-const int BUFFER_SIZE = sizeof(apr_off_t) * 3 + 2;
-char *buf = apr_palloc(p, BUFFER_SIZE);
-char *start = buf + BUFFER_SIZE - 1;
+int BUFFER_SIZE = sizeof(apr_off_t) * 3 + 2;
+char *buf, *start;
 int negative;
+
+/* apr_palloc aligns memory on 8 bytes (see apr_general.h).
+ * So, for small values of 'n', do not over-allocate some memory. */
+if (sizeof(apr_off_t) >= 4 && n<=999L && n>=-99L)
+BUFFER_SIZE = 8;
+
+buf = apr_palloc(p, BUFFER_SIZE);
+start = buf + BUFFER_SIZE - 1;
 if (n < 0) {
negative = 1;
n = -n;

Speed up 'apr_array_cat'

2011-08-08 Thread Christophe JAILLET 
Hi,

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 the dst table

We could :
   - allocate new memory
   - reset the memory that will remain uninitialised after copying dst and
src tables  <
   - copy the dst table to the new location
   - copy the src table after the dst table

Doing so, avoid the need to erase some memory.

A proposed, untested, patch is attached.

Best regards,
CJ


begin 666 diff_apr.patch
M26YD97@Z('1A8FQE2D*0$ @
M+3$U,RPX("LQ-3,L,3 @0$ *( D@(" @;F5W7W-I>F4@*CT@,CL*( E]"B *
M+0EN97=?9&%T82 ](&%PF4@
M*B!N97=?F4I.PHK
M(" @(&UE;7-E="AN97=?9&%T82 K("ADF4@*B H;F5W
M7W-I>F4@+2!D

Speed up 'apr_pstrdup'

2011-08-08 Thread Christophe JAILLET 
Hi,

'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
check.

A proposed, untested, patch is attached.

Best regards,
CJ


begin 666 diff_apr2.patch
M26YD97@Z('-T2D*0$ @+3