Re: svn commit: r1523853 - /apr/apr/trunk/test/sendfile.c

On Tue, Sep 17, 2013 at 2:18 AM, traw...@apache.org wrote: Author: trawick Date: Tue Sep 17 00:18:25 2013 New Revision: 1523853 Modified: apr/apr/trunk/test/sendfile.c URL: http://svn.apache.org/viewvc/apr/apr/trunk/test/sendfile.c?rev=1523853r1=1523852r2=1523853view=diff

Re: nonportable-atomics configure.in setting

I repost my comments here since they all went to the httpd list... On Wed, Dec 4, 2013 at 1:22 AM, Daniel Lescohier daniel.lescoh...@cbsi.comwrote: I see this in configure.in: AC_ARG_ENABLE(nonportable-atomics, [ --enable-nonportable-atomics Use optimized atomic code which may produce

Re: Event and atomics, round II

Hi, I cc to APR's dev list so to propose a patch regarding apr_atomic_dec32()platform dependent return values. On Mon, Jan 6, 2014 at 5:27 PM, Yann Ylavic ylavic@gmail.com wrote: On Mon, Dec 16, 2013 at 4:25 PM, Jim Jagielski j...@jagunet.com wrote: Now that 2.4.7 has been out

Re: Event and atomics, round II

On Wed, Jan 8, 2014 at 2:03 PM, Jim Jagielski j...@jagunet.com wrote: On Jan 7, 2014, at 3:15 PM, Jeff Trawick traw...@gmail.com wrote: +1 for APR trunk, +0.9 for future APR 1.6.x, -0.9 for APR 1.5.x... alternate opinions? As far as I know, C guarantees that if (a) is

Re: Event and atomics, round II

to a 0 would be extremely unlikely. You'd get an unexpected signed value, but I can't imagine any compiler turning it into a 0! On Jan 8, 2014, at 10:57 AM, Yann Ylavic ylavic@gmail.com wrote: On Wed, Jan 8, 2014 at 2:03 PM, Jim Jagielski j...@jagunet.com wrote: On Jan 7, 2014, at 3:15

New apr_sockaddr_info_copy() function

Hi, I'd like to propose the following/attached patch which adds the apr_sockaddr_info_copy() function to network_io. It can be useful when one wants an existing apr_sockaddr_t with a different lifetime (pool) without a DNS lookup, ie. a redundant/costly call to apr_sockaddr_info_get(). I hope

Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)

According to the man ( http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok() uses only the low-order 8-bits of the id. Maybe the APR could use the last char of the filename instead, so that the users knows and can choose it. For APR's internal/choosen filenames (if any), this

Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)

since APR consumers would need to be aware if that function exists or not. On Jan 24, 2014, at 6:00 PM, Yann Ylavic ylavic@gmail.com wrote: According to the man ( http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok() uses only the low-order 8-bits of the id. Maybe

Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)

On Sat, Jan 25, 2014 at 12:40 AM, Yann Ylavic ylavic@gmail.com wrote: Why couldn't APR document on using ftok(filename, filename[strlen(filename)-1]) for released versions, and do the right thing in trunk? ftok(filename, hash(filename)) is much better of course, I misread external

Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)

, at 6:40 PM, Yann Ylavic ylavic@gmail.com wrote: Why couldn't APR document on using ftok(filename, filename[strlen(filename)-1]) for released versions, and do the right thing in trunk? Is ftok(filename, 1) part of the ABI since the change would break existing consumers? I can't see any

Re: svn commit: r1561347 - /apr/apr/trunk/shmem/unix/shm.c

On Sat, Jan 25, 2014 at 6:57 PM, j...@apache.org wrote: Author: jim Date: Sat Jan 25 17:57:25 2014 New Revision: 1561347 URL: http://svn.apache.org/r1561347 Log: Revert mistaken c/p Modified: apr/apr/trunk/shmem/unix/shm.c Modified: apr/apr/trunk/shmem/unix/shm.c URL:

Re: svn commit: r1561347 - /apr/apr/trunk/shmem/unix/shm.c

/* APR_USE_SHMEM_MMAP_SHM */ /* store the real size in the metadata */ *(apr_size_t*)(new_m-base) = new_m-realsize; [END] On Sun, Jan 26, 2014 at 9:50 PM, Yann Ylavic ylavic@gmail.com wrote: On Sat, Jan 25, 2014 at 6:57 PM, j...@apache.org wrote: Author: jim Date: Sat Jan 25 17:57:25

Re: svn commit: r1561347 - /apr/apr/trunk/shmem/unix/shm.c

On Sun, Jan 26, 2014 at 9:54 PM, Yann Ylavic ylavic@gmail.com wrote: @@ -338,7 +322,7 @@ APR_DECLARE(apr_status_t) apr_shm_create(apr_shm_t return status; } /* TODO: should we use new_m-realsize instead of reqsize ?? */ It seems you already figured out

Re: New apr_sockaddr_info_copy() function

On Wed, Mar 12, 2014 at 11:08 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Looks like a good idea. Appropriate for trunk, and as mentioned to Jim r.e. Mladen's patch, great for 1.6.0. Since this is different than the httpd project, I'd point you to; http://apr.apache.org/versioning.html

apr_os_proc_mutex_get() segfault

Hi, when using the following code : pthread_mutex_t *mymutex; apr_proc_mutex_t *apmutex = NULL; apr_os_proc_mutex_t osmutex = {0}; apr_proc_mutex_create(apmutex, NULL, APR_LOCK_PROC_PTHREAD, p); apr_os_proc_mutex_get(osmutex, apmutex); mymutex = osmutex.pthread_interproc;

Re: apr_os_proc_mutex_get() segfault

On Mon, Apr 14, 2014 at 10:19 PM, Jeff Trawick traw...@gmail.com wrote: dev@apr has an aggravating reply-to setting :( Please try again to the list... Serious CTKI bug, still inverstigating :) On Sun, Apr 13, 2014 at 8:17 PM, Jeff Trawick traw...@gmail.com wrote: trunk r1587063 1.5.x

Re: New apr_sockaddr_info_copy() function

On Sun, Apr 13, 2014 at 7:12 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Jan 23, 2014 at 7:24 PM, Yann Ylavic ylavic@gmail.com wrote: Hi, I'd like to propose the following/attached patch which adds the apr_sockaddr_info_copy() function to network_io. Committed to APR trunk

Re: New apr_sockaddr_info_copy() function

Sorry, sent to Jeff only, again... On Tue, Apr 15, 2014 at 1:15 PM, Yann Ylavic ylavic@gmail.com wrote: Same patch attached. apr-trunk-apr_sockaddr_info_copy-test.patch Description: application/download

Re: make_tools_dir target in Makefile.in

On Thu, Apr 24, 2014 at 9:08 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Apr 22, 2014 at 5:15 AM, Yann Ylavic ylavic@gmail.com wrote: Index: Makefile.in === --- Makefile.in(revision 1589047) +++ Makefile.in

Re: permissions

Hello, I would be nice to have these in 1.6.x too. Regards, Yann. On Sat, Jan 25, 2014 at 6:47 PM, Jim Jagielski j...@jagunet.com wrote: Any reason why we've never pulled http://svn.apache.org/viewvc?view=revisionrevision=741869

Re: permissions

Thanks! On Mon, Apr 28, 2014 at 5:02 PM, Jim Jagielski j...@jagunet.com wrote: Added... On Apr 28, 2014, at 7:33 AM, Yann Ylavic ylavic@gmail.com wrote: Hello, I would be nice to have these in 1.6.x too. Regards, Yann. On Sat, Jan 25, 2014 at 6:47 PM, Jim Jagielski j

apr_sockaddr_info_copy() in 1.6.x?

Is it possible to add these too? http://svn.apache.org/r1587045 http://svn.apache.org/r1587543 Regards, Yann.

Re: apr_socket_opt_set always sets TCP_DEFER_ACCEPT to 1

On Tue, Apr 29, 2014 at 5:41 PM, Jim Jagielski j...@jagunet.com wrote: On Apr 22, 2014, at 9:43 AM, Brian J. France br...@brianfrance.com wrote: Doh, this is my bad: on != one http://svn.apache.org/viewvc/apr/apr/trunk/network_io/unix/sockopt.c?view=markup#l113 For some reason I

Re: apr_skiplist (current) implementation wrt mpm_event (timers, keepalives?)

On Tue, May 27, 2014 at 4:21 PM, Jim Jagielski j...@jagunet.com wrote: Check out r1597797 If OK, we can backport to 1.6 I would have preferred skiplist_insert() == skiplist_add(), since it seems to be needed by mpm_event (unless we require APR 1.6 for httpd-2.4.x). But I guess it's a

Re: apr_file_read() may return an error while bytes were read (windows only)

On Thu, Jun 12, 2014 at 4:12 PM, Yann Ylavic ylavic@gmail.com wrote: @@ -191,6 +192,10 @@ APR_DECLARE(apr_status_t) apr_file_read(apr_file_t if (thefile-flags APR_FOPEN_XTHREAD) { apr_thread_mutex_unlock(thefile-mutex

Re: apr_os_proc_mutex_get() segfault

Is there any chance this could be integrated into 1.6, or any fix that allows apr_os_proc_mutex_put/get() on posix semaphores (sem_t)? Regards, Yann. On Tue, Apr 15, 2014 at 12:37 AM, Yann Ylavic ylavic@gmail.com wrote: Also, it seems that the posix sems (ie. sem_t from semaphore.h

Re: fix a technicality with struct sockaddr_un in 1.6.x branch???

On Thu, Jun 19, 2014 at 8:15 PM, Jeff Trawick traw...@gmail.com wrote: But maybe Yann is working on a more useful revision that allows APR apps to take advantage of longer AF_UNIX paths? I dunno. I'm working on a patch for trunk where sockaddr_un is already in apr_sockaddr_t. Actually I

Re: fix a technicality with struct sockaddr_un in 1.6.x branch???

On Thu, Jun 19, 2014 at 8:31 PM, Yann Ylavic ylavic@gmail.com wrote: On Thu, Jun 19, 2014 at 8:15 PM, Jeff Trawick traw...@gmail.com wrote: But maybe Yann is working on a more useful revision that allows APR apps to take advantage of longer AF_UNIX paths? I dunno. I'm working on a patch

Re: Skiplist improvements

On Thu, Jul 10, 2014 at 9:55 PM, Jim Jagielski j...@jagunet.com wrote: On Jul 10, 2014, at 1:53 PM, Yann Ylavic ylavic@gmail.com wrote: The issue is that when a doublon is insert_compare()d, it will not necessarily (and even unlikely) be at the same height as the existing doublon(s

Re: Skiplist improvements

On Fri, Jul 11, 2014 at 4:28 PM, Jim Jagielski j...@jagunet.com wrote: On Jul 10, 2014, at 8:07 PM, Yann Ylavic ylavic@gmail.com wrote: I propose to garantee the ordering presumably at low coding and performance (if any) cost, so that one can choose between apr_table or apr_skiplist

Re: Skiplist improvements

Grr, off the list... On Fri, Jul 11, 2014 at 6:29 PM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Jul 11, 2014 at 6:24 PM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Jul 11, 2014 at 4:28 PM, Jim Jagielski j...@jagunet.com wrote: On Jul 10, 2014, at 8:07 PM, Yann Ylavic ylavic

Re: Skiplist improvements

On Fri, Jul 11, 2014 at 9:38 PM, Jim Jagielski j...@jagunet.com wrote: On Jul 11, 2014, at 12:29 PM, Yann Ylavic ylavic@gmail.com wrote: Maybe we could also leave skiplist as is and introduce a new type (skipmap?) that would be ordered and that would take both key and value as arguments

Re: Skiplist improvements

On Fri, Jul 11, 2014 at 9:57 PM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Jul 11, 2014 at 9:38 PM, Jim Jagielski j...@jagunet.com wrote: On Jul 11, 2014, at 12:29 PM, Yann Ylavic ylavic@gmail.com wrote: Maybe we could also leave skiplist as is and introduce a new type (skipmap

Re: Skiplist improvements

On Fri, Jul 11, 2014 at 9:58 PM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Jul 11, 2014 at 9:57 PM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Jul 11, 2014 at 9:38 PM, Jim Jagielski j...@jagunet.com wrote: On Jul 11, 2014, at 12:29 PM, Yann Ylavic ylavic@gmail.com wrote

Re: Skiplist improvements

On Fri, Jul 11, 2014 at 10:22 PM, Yann Ylavic ylavic@gmail.com wrote: There also seem to be some doubtful code in apr_skiplist_remove_all(), addressed by the following patch : Index: tables/apr_skiplist.c === --- tables

Re: svn commit: r1611193 - /apr/apr/trunk/tables/apr_skiplist.c

I think all the commits so far (r1611023, r1611107, r160, r167, r1611120, r1611125, r1611184 and 1611193) can be backported to 1.5.x, no API change (apr_skiplist.h is not modified). Another commit (I'm working on) will provide apr_skiplist_size(), apr_skiplist_height() and

Re: svn commit: r1611193 - /apr/apr/trunk/tables/apr_skiplist.c

On Thu, Jul 17, 2014 at 7:28 PM, Yann Ylavic ylavic@gmail.com wrote: I think all the commits so far (r1611023, r1611107, r160, r167, r1611120, r1611125, r1611184 and 1611193) can be backported to 1.5.x, no API change (apr_skiplist.h is not modified). Hm, wait, I didn't figure out

Re: svn commit: r1611193 - /apr/apr/trunk/tables/apr_skiplist.c

On Fri, Jul 18, 2014 at 2:20 AM, Yann Ylavic ylavic@gmail.com wrote: and 1.6.x (including your commits r1597797, 1597803 and r1605104 that introduce apr_skiplist_add, plus the latest r1611515 for apr_skiplist_size/height/preheight/set_preheight, all of which I think are good 1.6.x

Re: [VOTE] Release APR-util 1.5.4

On Wed, Sep 17, 2014 at 1:47 AM, Jeff Trawick traw...@gmail.com wrote: [ ] Release apr-util 1.5.4 as GA +1 All tests OK with : - Debian 6.0.10/squeeze/oldstable : * Linux-2.6.32-5-amd64, * gcc-4.3.5-4, * libssl-0.9.8o-4squeeze14 * libdb5-5.1.29-5 * libexpat1-2.0.1-7+squeeze1 *

New apr_hash_get_or_set()

Hello, I'm currently working on a code with a quite painful pattern (hot path) : value = apr_hash_get(key); if (value == NULL) { value = make_new_value(); apr_hash_set(key, value) } and would be interested in having the following apr_hash_get_or_set() function to do

Re: What's need for http/2.0?

On Tue, Sep 23, 2014 at 9:45 PM, Jim Jagielski j...@jagunet.com wrote: HTTPD: From the httpd point of view, what does serf provide for us to help us get to http/2.0? How about a new mod_proxy_http2 which can go async like in mod_proxy_wstunnel (trunk)? Some code could then be moved to

Re: What's need for http/2.0?

On Wed, Sep 24, 2014 at 11:10 PM, Yann Ylavic ylavic@gmail.com wrote: On Tue, Sep 23, 2014 at 9:45 PM, Jim Jagielski j...@jagunet.com wrote: HTTPD: From the httpd point of view, what does serf provide for us to help us get to http/2.0? How about a new mod_proxy_http2 which can go async

apr_os_proc_mutex_get/set[_ex] for supported mechanisms

Hi, as already said here http://mail-archives.apache.org/mod_mbox/apr-dev/201404.mbox/%3CCAKQ1sVOQ9ydgvNsDzj14=TPfbPQUg_fCZOGW=hmojpuw4cl...@mail.gmail.com%3E (which may have been lost in the atlantic ocean since it was quite out of topic), the current apr_os_proc_mutex_get/set() implementation

Re: apr_os_proc_mutex_get/set[_ex] for supported mechanisms

apr_proc_mutex_perms_set when the proc-mutex is global. All the rest remain as decribed below (previous message). On Tue, Sep 30, 2014 at 10:35 PM, Yann Ylavic ylavic@gmail.com wrote: the current apr_os_proc_mutex_get/set() implementation does not do the right thing nor allow very much about posix

[PATCH] apr_sockaddr with APR_UNIX socket paths longer than sizeof(sun_path)

Hello, the attached patch allows the APR to handle Unix Domain Socket paths longer than the the limit imposed by the size of struct sockaddr_un (for systems that support it, eg. *BSD), with no API/ABI change. To do so, new functions to manipulate the different type of addresses and socket

Skiplist index on demand

Hi, there seems to be no way to disable indexing in skiplist implementationn whereas the user may not need/use it (eg. httpd uses only insert(), pop() and peek()). When indexing is enabled (always for now), apr_skiplist_insert[_compare]() requires an additional insert to the index(es) for all

Re: apr_getnameinfo get localhost

172.18.4.3 IP: 172.18.4.3 HOST: (null) [root@myHOST ~]# -- Original -- From: Yann Ylavic;ylavic@gmail.com; Send time: Monday, Feb 2, 2015 5:03 PM To: aprdev@apr.apache.org; Subject: Re: apr_getnameinfo get localhost Oups, meant to send my reply

Re: apr_getnameinfo get localhost

Oups, meant to send my reply to the list... On Mon, Feb 2, 2015 at 10:01 AM, Yann Ylavic ylavic@gmail.com wrote: What does nslookup (or alike) output for these IPs ? On Mon, Feb 2, 2015 at 9:41 AM, GHui ugi...@gmail.com wrote: There is some error, so I resend again. [root@myHOST

Re: svn commit: r1667901 - /apr/apr/trunk/test/abts_tests.h

On Fri, Mar 20, 2015 at 12:40 AM, yla...@apache.org wrote: Author: ylavic Date: Thu Mar 19 23:40:51 2015 New Revision: 1667901 URL: http://svn.apache.org/r1667901 Log: Follow up to r1667900: revert spurious change on test/abts_tests.h. Modified: apr/apr/trunk/test/abts_tests.h

Re: svn commit: r1667901 - /apr/apr/trunk/test/abts_tests.h

On Fri, Mar 20, 2015 at 1:31 AM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Mar 20, 2015 at 1:22 AM, Yann Ylavic yla...@apache.org wrote: The strange thing is that it does not occur in 1.5.x for me (same code AFAICS). In fact no, actually: if (timeout 0) { timeout /= 1000

Re: svn commit: r1667901 - /apr/apr/trunk/test/abts_tests.h

On Fri, Mar 20, 2015 at 1:22 AM, Yann Ylavic yla...@apache.org wrote: The strange thing is that it does not occur in 1.5.x for me (same code AFAICS). In fact no, actually: if (timeout 0) { timeout /= 1000; } is outside #ifdef WIN32 there...

Re: svn commit: r1667901 - /apr/apr/trunk/test/abts_tests.h

On Fri, Mar 20, 2015 at 1:13 AM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 19, 2015 at 7:44 PM, Yann Ylavic yla...@apache.org wrote: --- apr/apr/trunk/test/abts_tests.h (original) +++ apr/apr/trunk/test/abts_tests.h Thu Mar 19 23:40:51 2015 @@ -50,9 +50,7 @@ const struct testlist

Re: Skiplist duplicates

On Sat, Mar 7, 2015 at 8:30 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Thu, 5 Mar 2015 11:19:40 -0500 Jim Jagielski j...@jagunet.com wrote: After doing some additional research, I think that the current implementation of NOT allowing duplicates (in APR 1.5/1.6) is BROKEN. In trunk

Re: Skiplist duplicates

On Sat, Mar 7, 2015 at 1:10 PM, Jeff Trawick traw...@gmail.com wrote: On Sat, Mar 7, 2015 at 5:03 AM, Yann Ylavic ylavic@gmail.com wrote: On Sat, Mar 7, 2015 at 8:30 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Thu, 5 Mar 2015 11:19:40 -0500 Jim Jagielski j...@jagunet.com

Re: Skiplist duplicates

On Sat, Mar 7, 2015 at 11:03 AM, Yann Ylavic ylavic@gmail.com wrote: It would be to give apr_skiplist_insert_compare(), which exists in 1.5.x, the add semantic when its compare function arg is NULL. Note this wouldn't break any assumption on apr_skiplist_insert_compare() since the current

Fwd: svn commit: r1664775 - /apr/apr/trunk/tables/apr_skiplist.c

Meant for the list... -- Forwarded message -- From: Yann Ylavic ylavic@gmail.com Date: Sun, Mar 8, 2015 at 11:34 AM Subject: Re: svn commit: r1664775 - /apr/apr/trunk/tables/apr_skiplist.c To: Jim Jagielski j...@jagunet.com On Sat, Mar 7, 2015 at 9:03 PM, Jim Jagielski j

Re: Skiplist duplicates

It seems that the implementation is not that broken actually. One can still have the add semantic with insert() in 1.5.x by using the appropriate compare function and apr_skiplist_insert_compare(), that is, a function that does not return 0 when entries are equal, but rather 0 for LIFO or 0 for

Re: svn commit: r1666483 - /apr/apr/branches/1.5.x/include/apr_skiplist.h

On Fri, Mar 13, 2015 at 4:33 PM, j...@apache.org wrote: Author: jim Date: Fri Mar 13 15:33:14 2015 New Revision: 1666483 URL: http://svn.apache.org/r1666483 Log: Describe the comp functions Modified: apr/apr/branches/1.5.x/include/apr_skiplist.h Modified:

Re: apr_os_proc_mutex_get/set[_ex] for supported mechanisms

only test this on linux (where all unixes mechanisms are available though), so review and (at least compile-)testing on other patforms much appreciated. Thanks, Yann. On Wed, Oct 1, 2014 at 4:24 PM, Yann Ylavic ylavic@gmail.com wrote: Here are v2 of the previous patch(es) with the following

Re: apr_os_proc_mutex_get/set[_ex] for supported mechanisms

(and there is one single choice for the mech), so in apr.h.in we can #define APR_PROC_MUTEX_IS_GLOBAL 1 for this platform. New patch (v4) attached, hence without point 2 below (the others remain), but with the change in apr.h.in described above. On Tue, Mar 24, 2015 at 10:41 PM, Yann Ylavic ylavic@gmail.com

Re: What is the lifetime of apr_dbd_get_entry(...); result?

I meant to reply to all... On Mon, Mar 2, 2015 at 11:23 AM, Yann Ylavic ylavic@gmail.com wrote: On Mon, Mar 2, 2015 at 8:22 AM, Jan Kaluža jkal...@redhat.com wrote: On 02/04/2015 02:53 PM, Jan Kaluža wrote: httpd's mod_authn_dbd module currently seems to expect that lifetime

Re: svn commit: r1664406 - in /apr/apr/trunk: include/apr_skiplist.h tables/apr_skiplist.c test/testskiplist.c

On Thu, Mar 5, 2015 at 5:51 PM, j...@apache.org wrote: Author: jim Date: Thu Mar 5 16:51:39 2015 New Revision: 1664406 URL: http://svn.apache.org/r1664406 Log: FIX: Skiplists should allow for dups by default. Also, when added, dups are added *after* each other, not before Modified:

Re: apr_os_proc_mutex_get() segfault

I was handling my late father's affairs last year. Is this still something that needs more eyeballs? Bill On Tue, 17 Jun 2014 23:57:17 +0200 Yann Ylavic ylavic@gmail.com wrote: Is there any chance this could be integrated into 1.6, or any fix that allows apr_os_proc_mutex_put/get

Re: Any concerns with a TR of apr 1.5.2 on Saturday a.m.?

On Thu, Apr 23, 2015 at 3:55 PM, Jeff Trawick traw...@gmail.com wrote: On 04/23/2015 09:33 AM, Yann Ylavic wrote: Should we add https://bz.apache.org/bugzilla/attachment.cgi?id=32643 from PR 55418? looks reasonable to me (not tested) I had tested it with: + case $host

Re: Any concerns with a TR of apr 1.5.2 on Saturday a.m.?

On Thu, Apr 23, 2015 at 3:55 PM, Jeff Trawick traw...@gmail.com wrote: warnings in test suite with Sun compiler on Solaris 10, some of which is from relatively new code (not researched, maybe the API is defined in a way that this compiler will never be happy): testatomic.c, line 208:

Re: Any concerns with a TR of apr 1.5.2 on Saturday a.m.?

On Thu, Apr 23, 2015 at 6:36 PM, Jeff Trawick traw...@gmail.com wrote: On 04/23/2015 12:09 PM, Yann Ylavic wrote: Commited in r1675670 (for 1.5.x). works fine on S10 circa 2008; I removed my --enable-non-portable-atomics flag (which would bypass the test) and verified that it still uses them

Re: Any concerns with a TR of apr 1.5.2 on Saturday a.m.?

On Thu, Apr 23, 2015 at 12:19 AM, Jeff Trawick traw...@gmail.com wrote: (subject says it all) +1

Re: [VOTE] Release APR 1.5.2

On Sat, Apr 25, 2015 at 3:39 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zipfiles are at http://apr.apache.org/dev/dist/ Shortcut to CHANGES: http://apr.apache.org/dev/dist/CHANGES-APR-1.5.2 autoconf version: 2.69 (same as apr 1.5.1) libtool version: 2.4.2 (same as apr 1.5.1) +/-1

Re: Any concerns with a TR of apr 1.5.2 on Saturday a.m.?

On Thu, Apr 23, 2015 at 12:19 AM, Jeff Trawick traw...@gmail.com wrote: (subject says it all) Should we add https://bz.apache.org/bugzilla/attachment.cgi?id=32643 from PR 55418? Also https://bz.apache.org/bugzilla/show_bug.cgi?id=55418#c4 suggests test suite may be broken for solaris (or is it

Re: svn commit: r1671390 - in /apr/apr/branches/1.6.x: ./ poll/unix/poll.c

On Sun, Apr 5, 2015 at 3:06 PM, Jeff Trawick traw...@gmail.com wrote: On 04/05/2015 09:00 AM, traw...@apache.org wrote: Author: trawick Date: Sun Apr 5 13:00:33 2015 New Revision: 1671390 URL: http://svn.apache.org/r1671390 Log: Merge r1671389 from trunk: poll() implementation of

GCC (only?) and strict aliasing rules

It seems that some versions of gcc still play bad with APR_RINGs when optimizations are on (O2). At least I can see warning when rings are created on the stack (eg. httpd's mpm_event, htcacheclean), and PR 57800 is possibly related (infinite loop with gcc-4.8 which I think is related to the

Re: [Patch] apr_file_path_merge returns incorrect truepath on certain 'short paths' on Windows

On Wed, Jun 17, 2015 at 5:41 AM, Branko Čibej br...@apache.org wrote: I went ahead and committed to trunk in r1685929. I'll see about porting this to 1.5.x. Maybe 1.6.x too?

Re: How to release apr_socket_accept memory pool

On Thu, Aug 20, 2015 at 4:12 AM, GHui ugi...@gmail.com wrote: On Thu, 2015-08-20 at 6:30 AM , Nick wrote: Can you not solve that problem by using a subpool for those functions? That way you can give the subpool the lifetime you need it to have, regardless of other resources that prevent you

Re: Issues/questions with apr_memcache_multigetp

' ', no? >> >> https://github.com/memcached/memcached/blob/master/doc/protocol.txt#L227 >> >> I'm not really quite sure if the protol description is correct. >> >> Should it in fact read >> >> VALUE [ ]\r\n >> >> instead of >> >

Re: Issues/questions with apr_memcache_multigetp

Hi Jeffrey, On Wed, Sep 23, 2015 at 9:23 PM, Jeffrey Crowell wrote: > > We have some patches which were created in an attempt to fix some signed > bugs in the original code that I think may be causing our issue. > > Namely here: >

PROC_PTHREAD_MUTEX refcounting

PROC_PTHREAD_SERIALIZEThe current PROC_PTHREAD_SERIALIZE implementation mmap()s a shared pthread_mutex_t (PTHREAD_PROCESS_SHARED), and the cleanup calls both pthread_mutex_destroy() and munmap() when the pool used with _create() is cleared or _destroy() is called explicitly. In the (common) case

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

gt; in the morning with lots of room for optimization. On Nov 30, 2015 11:20, "Yann Ylavic" <ylavic@gmail.com> wrote: Sorry for the late, was afk this times... Regarding the name, I'm fine with ap[r]_cstr[n]casecmp(), ap[r]_casecmpcstr[n]() or ap[r]_cstr_*() (if we need a se

Re: Optimization, modern C and APR 2.0 onwards

On Fri, Nov 20, 2015 at 8:00 PM, Jim Jagielski wrote: > If we are serious about having a serious update to APR, I > would recommend that we use more up-to-date data structures, > patterns and algorithms than those in apr1. For example, > Greg's pocore mini lib is an example of

Re: Optimization, modern C and APR 2.0 onwards

On Fri, Nov 20, 2015 at 11:14 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Fri, Nov 20, 2015 at 2:55 PM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> On Fri, Nov 20, 2015 at 8:00 PM, Jim Jagielski <j...@jagunet.com> wrote: >> > If we are se

Re: Provide our own impl of str[n]casecmp()?

on Road > #34-11 International Plaza > Singapore 079903 > Tel: (65) 6334 8311 > Fax: (65) 6334 8511 > na...@fortressintelligence.com.sg > www.fortressintelligence.com.sg > > -Original Message- > From: Yann Ylavic [mailto:ylavic@gmail.com] > Sent: Saturday, 21 No

Re: Provide our own impl of str[n]casecmp()?

On Sat, Nov 21, 2015 at 12:59 PM, Branko Čibej wrote: > On 21.11.2015 09:31, Graham Leggett wrote: >> On 21 Nov 2015, at 12:11 AM, William A Rowe Jr wrote: >> >>> Any objections to picking this up for APR 1.next/2.0? >>> >>> It seems that httpd isn't the

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Jan 27, 2016 at 1:17 AM, William A Rowe Jr wrote: > > Yann, I didn't pick up our research yet to tweak the SVN implementation, > since we never really tested that. The signed->unsigned transition is a > noop, > so the only question is the fastest way to structure the

Re: svn commit: r1733775 - in /apr/apr/trunk: ./ include/ include/arch/unix/ locks/beos/ locks/netware/ locks/os2/ locks/unix/ locks/win32/

[resend: list's reply policy strikes again :/ ] On Mon, Mar 7, 2016 at 12:47 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Mon, Mar 7, 2016 at 10:52 AM, Ruediger Pluem <rpl...@apache.org> wrote: >> >> On 03/06/2016 01:19 AM, yla...@apache.org wrote: >&g

Re: [PATCH] Add support for IP_FREEBIND sockopt (PR58725)

On Thu, Mar 3, 2016 at 4:52 PM, William A Rowe Jr wrote: > Sources written for 1.5.3 would no longer be source compatible with 1.5.2, > so this is a change for 1.6.0. I see, thanks for clarifying.

Re: svn commit: r1733451 - in /apr/apr/trunk: include/apr_network_io.h network_io/unix/sockopt.c test/testsock.c

On Thu, Mar 3, 2016 at 1:00 PM, wrote: > Author: jorton > Date: Thu Mar 3 12:00:20 2016 > New Revision: 1733451 > > URL: http://svn.apache.org/viewvc?rev=1733451=rev > Log: > * include/apr_network_io.h (APR_SO_FREEBIND): Add option. > > * network_io/unix/sockopt.c

Re: [PATCH] Add support for IP_FREEBIND sockopt (PR58725)

On Thu, Mar 3, 2016 at 1:17 PM, Joe Orton wrote: > > q for the list: Does APR normally avoid adding new API-ish things in > stable branches or can I add this to 1.5.x too? I think a new #define which has negligeable chances to collide with any existing one is only "patch

OS/2's pollcb in 1.5 / 1.6

Since we are pushing latest pollcb changes to 1.6, and pollcb is 1.5 already, I wonder why poll/os2/pollcb.c is not committed in these branches. Doesn't it raise a linker error to resolve apr_pollcb_*() functions on OS/2?

Re: [PATCH] Fix locks/win32/proc_mutex.c compilation on Windows

On Thu, Aug 11, 2016 at 1:24 PM, Ivan Zhakov wrote: > Currently APR build fails on Windows due small type on > locks/win32/proc_mutex.c: > [[ > locks\win32\proc_mutex.c(252): error C2065: 'mutex' : undeclared identifier > ]] > > Attached patch fixes this error. Thanks Ivan,

Re: svn commit: r1736521 - in /apr/apr/branches/1.6.x: ./ include/ include/arch/unix/ poll/unix/ test/

Hi Rainer, On Wed, Aug 10, 2016 at 12:41 PM, Rainer Jung wrote: > I found some more differences between trunk and r1736521 in 1.6.x which are > all due to incomplete backports of changes applied to trunk after r899905. I > backported all of those because they seemed

Re: Debugging segfaults and in general, memory pools

Hello Tony, On Tue, Feb 7, 2017 at 10:38 PM, Antonio Mammita wrote: > > I tried to use APR compiled with --enable-debug, --enable-pool-debug, > --enable-mantainer-mode but nothing has helped. > > I think that a memory pool allocator that would just use malloc() could help >

Re: Difference between TARBALL and SVN checkout

Please simply send some mail to "dev-unsubscr...@apr.apache.org" Regards, Yann. On Sun, Feb 5, 2017 at 4:27 AM, Rahul Kumar Jha wrote: > Please Remove me from your mailing list. Kindly don't send spam. > > Thanks > > > > On Sat, Feb 4, 2017 at 8:39 PM Luke Perkins

Re: Difference between TARBALL and SVN checkout

On Sat, Feb 4, 2017 at 5:39 PM, Luke Perkins wrote: > > It appears that I am missing a part of the setup instructions for building > the apr from SVN checkout vs. the apr-1.5.4 tarball. > > I can build the tarball version without issue. However, when I perform an > SVN

Re: APR pools, mutexes and thread safe allocations

On Mon, Feb 20, 2017 at 4:43 PM, Jim Jagielski wrote: > You are confusing pool mutexes with allocator mutexes... I'm not sure to understand, there is no pool mutex per se currently, the mutex (if any) used by the pool is its allocator's. So as Brane says, if one sets a mutex to

Re: APR pools, mutexes and thread safe allocations

Well, this is for debug mode only I guess. On Mon, Feb 20, 2017 at 4:59 PM, Jim Jagielski <j...@jagunet.com> wrote: > Please READ apr_pools.c... Search for '->mutex' > >> On Feb 20, 2017, at 10:58 AM, Yann Ylavic <ylavic@gmail.com> wrote: >> >> On Mon,

Re: APR pools, mutexes and thread safe allocations

On Mon, Feb 20, 2017 at 5:55 PM, Jim Jagielski wrote: > >> >> It could be done, but who would use it that way? >> > > I think the non-thread safety of pools requires that each > person/developer implement their own locking esp around areas > where they might not even understand

Re: svn commit: r1783755 - /httpd/httpd/trunk/server/mpm/event/event.c

[Oups, meant to reach the list(s)]. On Mon, Feb 20, 2017 at 3:46 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Mon, Feb 20, 2017 at 3:16 PM, Jim Jagielski <j...@jagunet.com> wrote: >> The below got me thinking... >> >> Right now, the pool alloca

Allocator nodes of a single page

Hello, the attached patch modifies the allocator (and pool) to allow for order-0 nodes/allocations (2^0, one page, 4K on most CPUs). The pools are still created with order-1 (two pages) by default, but one can use the new apr_pool_order_set(order) function at any time (preferable init time) to

Re: SHA256 and friends.

On Fri, Jan 20, 2017 at 4:19 PM, Dirk-Willem van Gulik wrote: > > Ok so if we had a special #ifdef for 'TRUE_MD5 and would manually tweak/mark > up the 2 or 3 places > that we know we need a real MD5 - we could have a 'fiddle' mode where we > silently return a better 'md5'

Re: SHA256 and friends.

On Fri, Jan 20, 2017 at 9:22 AM, Dirk-Willem van Gulik wrote: > > As to the selection of the hash - I can see three strategies > > A) current approach (we do this I think only for sha256): > > apr_crypto_hash_t * ctx = apr_crypto_sha256_new(pool); > >

Re: SHA256 and friends.

On Fri, Jan 20, 2017 at 1:01 PM, Dirk-Willem van Gulik <di...@webweaving.org> wrote: > On 20 Jan 2017, at 12:53, Yann Ylavic <ylavic@gmail.com> wrote: >>> >>>apr_hash(sha256_ctx, , , plain, plainlen, pool); >> >> Probably apr

  1   2   3   4   5   >