Re: [VOTE] release apr-util-1.6.2-rc2 as apr-util 1.6.2

> On Jan 23, 2023, at 1:57 PM, Eric Covener wrote: > > 1.6.2-rc2 is here: > > https://apr.apache.org/dev/dist/ > > For the release of apr-util-1.6.2 > [X] +1 looks great! > [ ] -1 something is broken > > I will let the vote run through mid-week and then try to finalize APR > and APU

Re: VOTE: Release apr-1.7.1-rc2 as 1.7.1

> On Jan 19, 2023, at 7:44 PM, Eric Covener wrote: > > 1.7.1-rc1 is here: > > https://apr.apache.org/dev/dist/ > > For the release of apr-1.7.1 > [ X] +1 looks great! > [ ] -1 something is broken > > I will let the vote run through mid-week. > macOS 12.6.2 / Xcode 14.2

Re: malloc, calloc and APR pools

8k -> 512k > On Nov 14, 2022, at 3:57 AM, Ruediger Pluem wrote: > > > > On 11/13/22 4:23 PM, Jim Jagielski wrote: >> This article (https://vorpus.org/blog/why-does-calloc-exist/) >> looks like it's very applicable to APR, where we do the exact >> malloc

malloc, calloc and APR pools

This article (https://vorpus.org/blog/why-does-calloc-exist/) looks like it's very applicable to APR, where we do the exact malloc-memset trick. Prelim testing on my macOS and Linux machines do show appreciable improvements. At the very least, maybe a compile-time flag??

Re: Named shared memory on macOS Monterey

ded? I've > lost the errors, ended up commenting out the mod and re-running > Makefiles.PL to get unblocked. > > On Tue, May 17, 2022 at 3:26 PM Jim Jagielski wrote: >> >> Anyone else notice that the later version of macOS really prefer >> that APR use posix for sha

Named shared memory on macOS Monterey

Anyone else notice that the later version of macOS really prefer that APR use posix for shared memory for both anon and name-based, instead of posix for anon and sysv/ipc for name? The issue seems to be that the kernel params are much lower than previous versions as well as it being

Re: Xcode 12

Yep... I fixed both versions. > On Nov 12, 2020, at 4:24 AM, Branko Čibej wrote: > > On 29.10.2020 21:01, Christopher Schultz wrote: >> Jim, >> >> On 10/29/20 10:04, Jim Jagielski wrote: >>> Anyone hacking away on httpd and/or APR w/ Xcode 12? On my system

Xcode 12

Anyone hacking away on httpd and/or APR w/ Xcode 12? On my system at least it is throwing errors about -Werror,-Wimplicit-function-declaration, and not enabling IPv6: checking if APR supports IPv6... no -- no working getaddrinfo also likely due to an error when compiling because of

Warning: Xcode12 breaks apr* and httpd

The upgrade from Xcode11 -> Xcode12 has been reported to break builds for APR and httpd... Issues seem to be some sort of forced C99 compliance and not discovering IPv6 capability. I'm not upgrading anytime soon so no idea how bad it is.

Re: Proposal: apr-tools project

> On Jul 25, 2019, at 7:22 AM, Graham Leggett wrote: > > Hi all, > > Disclaimer: I don’t have time to do this right now, but at some point soon I > would like to get something like this done. > > I propose the creation of, in addition to apr and apr-util, the apr-tools > project. > >

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

So far, no luck in recreating on either 10.13 or 10.12... > On Jun 14, 2019, at 12:41 PM, Jim Jagielski wrote: > > I cannot recreate But then again, I am on 10.14.x and the build server is > 10.13, so it could be something there. > > I have some old macOS VMs around I

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

I cannot recreate But then again, I am on 10.14.x and the build server is 10.13, so it could be something there. I have some old macOS VMs around I use for OpenOffice builds. I'll try on them. > On Jun 11, 2019, at 3:14 PM, Branko Čibej wrote: > > On 11.06.2019 18:36, build...@apache.org

Re: The case for apr-util-2.0

> On Jun 6, 2019, at 5:04 AM, Graham Leggett wrote: > > On 06 Jun 2019, at 07:07, Mladen Turk wrote: > >> IMO, all that third party library wrappers should not be part of >> apr. Anything from apr-util can go to apr (as it should in the first place), >> but all those dbm, db, odbc, ldap or

Re: apr 1.7.0 configure fails on macOS with Xcode 10.2.1 SDK MacOSX10.14.sdk

Does setting the env-var MACOSX_DEPLOYMENT_TARGET not work? > On Apr 26, 2019, at 6:22 AM, Barry Scott wrote: > > I have found the problem and its in the way I setup CFLAGS and LDFLAGS. > > In the past it was necessary to setup the env like this so that the build use > the Mac OSX SDK so that

Re: [vote] Release apr-1.7.0 ?

> On Apr 1, 2019, at 2:01 PM, William A Rowe Jr wrote: > > Candidate tarballs are at the usual location; > https://apr.apache.org/dev/dist/ > > For the release of apr-1.7.0 > [ ] +1 looks great! +1 for release: macOS 10.14.4, Xcode 10.2. Thx for RMing! Full output of 'make check'

Re: Showstoppers to 1.7.0?

Yep, all good. Thx! > On Mar 19, 2019, at 3:12 PM, William A Rowe Jr wrote: > > On Tue, Mar 19, 2019 at 1:51 PM Jim Jagielski <mailto:j...@jagunet.com>> wrote: > Under OSX/macOS, whether off_t and/or size_t are long long or long > depends on compile time and the actual

Re: Showstoppers to 1.7.0?

OSX 10.7 (the oldest I have) thru 10.14 using both official Apple Xcode cc/clang and MacPorts gcc. > On Mar 19, 2019, at 2:30 PM, William A Rowe Jr wrote: > > On Tue, Mar 19, 2019 at 12:58 PM Jim Jagielski <mailto:j...@jagunet.com>> wrote: > > Hi Bill, can you let me

Re: Wrong definition of APR_OFF_T_FMT in apr.h

n, Stefan could you share your > config.log/config.status, and resulting app.h file, so I can diagnose the > misassumption here? > > > > > On Fri, Mar 15, 2019, 06:44 wuzhouhui <mailto:wuzhouhu...@mails.ucas.ac.cn>> wrote: > > > On Mar 15, 2019,

Re: Wrong definition of APR_OFF_T_FMT in apr.h

for the extra info! > On Mar 14, 2019, at 7:49 PM, wuzhouhui wrote: > >> >> On Mar 15, 2019, at 5:44 AM, William A Rowe Jr wrote: >> >> Jim, Stefan, wuzhouhui... >> >> On Wed, Mar 13, 2019 at 3:13 PM Jim Jagielski wrote: >>> >>>

Re: Wrong definition of APR_OFF_T_FMT in apr.h

m, Stefan, wuzhouhui... > > On Wed, Mar 13, 2019 at 3:13 PM Jim Jagielski <mailto:j...@jagunet.com>> wrote: > > > > FWIW, I have apr-1.6 here and cannot confirm the below. When compiling w/ > > httpd, DARWIN_10 is defined as required. > > > > > On

Re: Showstoppers to 1.7.0?

> On Mar 14, 2019, at 9:06 AM, Stefan Sperling wrote: > > On Thu, Mar 14, 2019 at 07:49:41AM -0400, Jim Jagielski wrote: >> I use maintainer-mode all the time... as I said, building httpd does not >> cause any errors due to APR_SSIZE_T_FMT > > Ah, sorry

Re: Showstoppers to 1.7.0?

I use maintainer-mode all the time... as I said, building httpd does not cause any errors due to APR_SSIZE_T_FMT > On Mar 14, 2019, at 2:16 AM, Stefan Sperling wrote: > > On Wed, Mar 13, 2019 at 04:22:46PM -0400, Jim Jagielski wrote: >> Just a FYI that compiling httpd trunk (HE

Re: Showstoppers to 1.7.0?

Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and apu-1.6 (HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm not exactly sure where these are coming from for macOS % uname -a Darwin jimsys.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST

Re: Wrong definition of APR_OFF_T_FMT in apr.h

FWIW, I have apr-1.6 here and cannot confirm the below. When compiling w/ httpd, DARWIN_10 is defined as required. > On Mar 3, 2019, at 9:26 AM, wuzhouhui wrote: > > Hi, > > I found a compile warning in APR, following is a C program that will > report warning when compiled in my system: > >

Using APR pools "better"

At ApacheCon's welcoming event last night, Greg, Sander and I were chatting and Greg reminded us that the Subversion project "learned a lot about using APR pools" and it seems to me that a lot of that knowledge is likely missing in httpd-land. I also know that some of that has been backported

Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

Moved from httpd dev (which was moved to BCC) > On Sep 17, 2018, at 2:54 PM, Yann Ylavic wrote: > > On Mon, Sep 17, 2018 at 5:52 PM Jim Jagielski wrote: >> >> Would like to also propose for apr-1.7... > > How about 128bit? :p > > There are __int128 (gcc

Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

> On Sep 18, 2018, at 9:53 AM, Jim Jagielski wrote: > > > >> On Sep 18, 2018, at 9:33 AM, Ruediger Pluem wrote: >> >> >> >> On 09/17/2018 05:50 PM, j...@apache.org wrote: >>> Author: jim >>> Date: Mon Sep 17 15:50:19 2018 &

Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

> On Sep 18, 2018, at 9:33 AM, Ruediger Pluem wrote: > > > > On 09/17/2018 05:50 PM, j...@apache.org wrote: >> Author: jim >> Date: Mon Sep 17 15:50:19 2018 >> New Revision: 1841078 >> >> URL: http://svn.apache.org/viewvc?rev=1841078=rev >> Log: >> Add in Atomics for 64bit ints >> >>

Fwd: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/

Would like to also propose for apr-1.7... > Begin forwarded message: > > From: j...@apache.org > Subject: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp > atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c > include/apr_atomic.h

Re: Making proxy "busy" atomic and implement a busy limit

e mistaken. > On Sep 17, 2018, at 10:03 AM, Nick Kew wrote: > > Apologies to Jim. Sent this to him, meant for the dev list of course. > >>> On 17 Sep 2018, at 14:18, Jim Jagielski wrote: >>> >>> FYI: Both clang and GCC support both __sync and __a

Re: Making proxy "busy" atomic and implement a busy limit

FYI: Both clang and GCC support both __sync and __atomic which support 64bit ints. We could add that functionality to APR... > On Sep 17, 2018, at 8:57 AM, Jim Jagielski wrote: > > In principle, I agree w/ making these counters atomic... up to now, some > minor discrepancies fro

Re: [VOTE] apr-1.6.5 release

+1: macOS 10.13.6, Xcode 9.4.1 CentOS 5, 6 > On Sep 10, 2018, at 5:22 PM, William A Rowe Jr wrote: > > 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

Re: [VOTE] apr-1.6.4 release?

So I guess I'm a -1 on release due to this. > On Sep 8, 2018, at 5:03 AM, Rainer Jung wrote: > > Correct, r1839769 plus backports are the culprit. Looks like "tm->" must be > replaced by "(*ostime)->" or similar in line 302: > > if ((*ostime)->wMonth < 1 || (*ostime)->wMonth > 12) > > I

Re: 1.6 release?

If no one volunteers, I will. > On Aug 24, 2018, at 9:16 AM, Eric Covener wrote: > > Starting a new thread as potential RM's may be filtering bugzilla emails. > > There are a lot of reports of PR62644 from solaris users of httpd, can > anyone RM? > > -- > Eric Covener > cove...@gmail.com

Re: [RFC] apr_array_find()

FWIW, I also agree w/ Greg's PoV regarding this. > On Apr 27, 2018, at 3:23 PM, Greg Stein wrote: > > At one point, we used to use an svn_array_find() or some such. We deprecated > it. Creating a function to do comparisons, then set up a function call... It > was just

Re: svn commit: r1828369 - in /apr/apr/trunk: include/apr_reslist.h util-misc/apr_reslist.c

> On Apr 16, 2018, at 7:22 AM, Ruediger Pluem wrote: > > > > I think there are scenarios where LIFO is useful, but the question is if > these are frequent enough to warrant LIFO / > FIFO as an option. > As an option, yes. But not, in my opinion, a behind-the-curtains

Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases

I've built and tested on macOS 10.12. All good. +1 (binding) Thx for RMing! > On Oct 18, 2017, at 10:58 AM, William A Rowe Jr wrote: > > Please cast your votes on the following candidate packages; > > Release apr-1.6.3 > [ ] +1 looks good > [ ] +/-0 since > [ ] -1

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

X specific backport included. > > Note that the proposed httpd fix is still uneasy about the trunk flavor; > https://ci.apache.org/builders/httpd-trunk/builds/1202 > <https://ci.apache.org/builders/httpd-trunk/builds/1202> > > > > On Mon, Oct 16, 2017 at 1:11 PM,

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

The APR fix just handles macOS w/ Xcode9 or clang 5.0.0. -Werror can be set "externally" and whether or not we should actually die is debatable. But considering that AC_CHECK_LIB will never use function prototypes, the long term solution may be to simply never use that. I'm +0 on removing the

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

I'd be +1 on setting -Wno-error=strict-prototypes unconditionally > On Oct 15, 2017, at 11:52 AM, Rainer Jung wrote: > > Am 15.10.2017 um 16:25 schrieb Yann Ylavic: >> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung wrote: >>> >>> Why is this

AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

Let's recall what is really happening... In maintainer mode, the build system sets -Werror and -Wstrict-prototypes. This means that functions which lack strict prototypes will "fail". Now note that AC_CHECK_LIB does not worry about generating function calls w/ prototypes, so, for example, when

Re: Talking json

> On Sep 3, 2017, at 11:46 AM, Torge Riedel wrote: > > Am 13.03.2016 um 01:03 schrieb Nick Kew: >> Hi, >> >> I'm working on a module for HTTPD that needs to talk json: >> read client requests, and send responses. >> >> Before I re-invent this particular wheel, is anyone

Re: Talking json

> On Mar 13, 2016, at 1:41 PM, Luca Toscano wrote: > > Hi Nick, > > 2016-03-13 1:03 GMT+01:00 Nick Kew : > > Before I re-invent this particular wheel, is anyone aware > of existing code under apache-compatible license that parses > json to an APR table

Re: Bugs in apr_file_trunc

Thx. Committed revision 1800458 for 1.6.x > On Jun 30, 2017, at 2:24 PM, Ivan Zhakov wrote: > > 1788929

Re: Bugs in apr_file_trunc

Thx... it's a shame that either (1) these bugs aren't reported to the APR dev team to fix or (2) that they are, but that the dev team isn't aware or following up. Either alternative is sad. > On Jun 30, 2017, at 10:49 AM, Julian Foad wrote: > > It came to my notice that

Declares and r1798638

Still looks like an issue from http://svn.apache.org/viewvc?view=revision=1798638 In file included from crypto/apr_siphash.c:22: /Users/jim/src/asf/code/dev/httpd-2.4/srclib/apr-util/include/apr_siphash.h:69:27: error: expected function body after function declarator APU_DECLARE(apr_uint64_t)

Re: [VOTE] Release APR 1.6.2

+1 > On Jun 9, 2017, at 9:09 AM, William A Rowe Jr wrote: > > With good fortune, all architecture-specific issues are fixed, > and we are ready to bless a 1.6 initial release. Usual > http://apr.apache.org/dev/dist/ path contains the candidate. > > +/- votes please > [ ]

Re: [VOTE] Release APR-UTIL 1.6.0

+1. > On Jun 9, 2017, at 9:07 AM, William A Rowe Jr wrote: > > As I mention in parent post, this is a distinct thread for any > final votes and to tally vote count of apr-util 1.6.0 release. > Usual http://apr.apache.org/dev/dist/ path for candidates. > > +/- votes please

Re: Target 1.6.1?

Looking fine for macOS > On May 30, 2017, at 11:06 AM, Nick Kew wrote: > > It's looking fine since Bill's surgical work last week. > > I'm minded to T apr-1.6.1 tomorrow, and put it up > along with apr-util-1.6.0 for vote as Release Candidates. > > Any objections? > > -- >

Re: [VOTE] Release _timedlock API in 1.6.x?

I am conflicted... I'm still now sure what the real expected use-cases are, and don't feel that it's quite solid/stable enough for inclusion. But on the other hand, knowing the delays we have between API-changing releases, NOT having it in 1.6 basically puts it to bed for a long, long time, in

Re: Et resurrexit tertia die.

Or even 1.7? :) > On Apr 10, 2017, at 9:35 AM, William A Rowe Jr wrote: > > Agreed across the board. 1 has fixes and concensus, 2-4 can be fixed in 2.0. > > There is a fix for the appearance of offline resources on Windows as > symlinks, only junctions and symlinks to

Re: Et resurrexit tertia die.

+1... Let's make it so.

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

> On Apr 7, 2017, at 9:53 AM, Branko Čibej <br...@apache.org> wrote: > > On 07.04.2017 14:38, Jim Jagielski wrote: >> You are assuming that the dev directly sets the timeout... what if it >> is calculated and somehow the calc'd time is negative. To me >&g

Re: svn commit: r1790490 - in /apr/apr/branches/1.6.x: ./ include/ include/arch/unix/ locks/beos/ locks/netware/ locks/os2/ locks/unix/ locks/win32/ test/

Fixed as of r1790546 > On Apr 7, 2017, at 8:39 AM, Jim Jagielski <j...@jagunet.com> wrote: > > New error: > > /bin/sh /Users/jim/src/asf/code/dev/apr-trunk/libtool --silent --mode=compile > gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK > -D

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

You are assuming that the dev directly sets the timeout... what if it is calculated and somehow the calc'd time is negative. To me that means that it's "too late" and the expected result would be a timeout, instead they would wait forever. This seems non intuitive to me.

Re: svn commit: r1790490 - in /apr/apr/branches/1.6.x: ./ include/ include/arch/unix/ locks/beos/ locks/netware/ locks/os2/ locks/unix/ locks/win32/ test/

New error: /bin/sh /Users/jim/src/asf/code/dev/apr-trunk/libtool --silent --mode=compile gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I../include -I./../include -I/usr/local//include -o testlockperf.lo -c testlockperf.c && touch testlockperf.lo

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

We are creating these from scratch, not adding additional functionality to something that already exists. :/ > On Apr 7, 2017, at 4:21 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Fri, Apr 7, 2017 at 2:28 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: >>

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

> On Apr 6, 2017, at 4:25 PM, Jacob Champion wrote: > > > A zero or negative timeout should attempt to instantaneously acquire, and > return TIMEUP immediately if that's not possible. Treating negative values > the same way as zero allows client code to handle

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

As of HEAD on apr-trunk, all tests pass fine on OSX. Plus: ./include/arch/unix/apr_private.h:#define HAVE_PTHREAD_CONDATTR_SETPSHARED 1 So I'm +1 for backporting to 1.6! > On Apr 6, 2017, at 2:49 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Thu, Apr 6, 2017 at 1:40 PM

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

apr-trunk (r1790379): % ./testall -v testprocmutex testprocmutex : -Line 189: Locks don't appear to work with timedlock -flock_timedlock() not implemented,/Line 189: Locks don't appear to work with timedlock -Line 189: Locks don't appear to work with timedlock -fcntl_timedlock()

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

> On Apr 5, 2017, at 2:22 PM, Yann Ylavic wrote: > > > My reasoning is rather that we implement a generic pshared condvar > solution (like we do for thread-mutexes), and if it does not work on > OSX (because for some reasons their condvar does not work as > advertised or

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

> On Apr 5, 2017, at 2:03 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Wed, Apr 5, 2017 at 7:45 PM, Jim Jagielski <j...@jagunet.com> wrote: >> In fact, that goes for all, really. All *.timedacquire() impl >> should return APR_TIMEUP for any timeout < 0

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

In fact, that goes for all, really. All *.timedacquire() impl should return APR_TIMEUP for any timeout < 0. Instead we try to acquire which is against the whole ABI guarantee. > On Apr 5, 2017, at 1:37 PM, Jim Jagielski <j...@jagunet.com> wrote: > > If the timeout has exp

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

> On Apr 5, 2017, at 1:28 PM, Nick Kew wrote: > > On Wed, 5 Apr 2017 10:53:30 -0500 > William A Rowe Jr wrote: > Howbout a --with-experimental-timedlocks config option ? >>> >>> +1 >>> >>> although anyone toggling an -experimental flag is expected

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

If the timeout has expired, shouldn't we return APR_TIMEUP? > On Apr 5, 2017, at 1:25 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Wed, Apr 5, 2017 at 7:14 PM, Jim Jagielski <j...@jagunet.com> wrote: >> Your log is: >> >> Follow up to r1667900: s

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

r 5, 2017, at 1:06 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Wed, Apr 5, 2017 at 6:57 PM, Jim Jagielski <j...@jagunet.com> wrote: >> This does not seem correct at all... Why are we calling >> proc_mutex_sysv_tryacquire(mutex)?? > > Because the user as

Re: svn commit: r1790296 - /apr/apr/trunk/locks/unix/proc_mutex.c

This does not seem correct at all... Why are we calling proc_mutex_sysv_tryacquire(mutex)?? > On Apr 5, 2017, at 12:24 PM, yla...@apache.org wrote: > > Author: ylavic > Date: Wed Apr 5 16:24:00 2017 > New Revision: 1790296 > > URL: http://svn.apache.org/viewvc?rev=1790296=rev > Log: > Follow

Re: No timed lock on MacOS

r 5, 2017, at 10:25 AM, Branko Čibej <br...@apache.org> wrote: > > On 05.04.2017 14:16, Jim Jagielski wrote: >> Hmmm Looking over the timed stuff, it seems that semtimedop() >> is used incorrectly. >> >> For both pthread_mutex_timedlock() and sem_timedwait()

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

and/or Posix versions? > On Apr 5, 2017, at 9:11 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Wed, Apr 5, 2017 at 6:46 AM, Jim Jagielski <j...@jagunet.com> wrote: >> >>> On Apr 5, 2017, at 6:39 AM, Yann Ylavic <ylavic@gmail.com> wrote: >>&

Re: No timed lock on MacOS

Hmmm Looking over the timed stuff, it seems that semtimedop() is used incorrectly. For both pthread_mutex_timedlock() and sem_timedwait(), the timeout variable is the actual wallclock time that the wait expires (eg: now+5mins). But, from what I can read about semtimedop(), its timeout really

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

> On Apr 5, 2017, at 6:39 AM, Yann Ylavic wrote: > > > Agreed, there seems to be few (if any) alternatives, though, but: > avoid using apr_proc/global_mutex_timedlock() on OSX is recommended. > Should we make it explicit with ENOTIMPL? > Maybe we should reconsider the

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

We *could* consider using macOS native for everything... Ugg.

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

> On Apr 5, 2017, at 6:42 AM, Branko Čibej <br...@apache.org> wrote: > > On 05.04.2017 12:39, Yann Ylavic wrote: >> On Wed, Apr 5, 2017 at 12:27 PM, Branko Čibej <br...@apache.org> wrote: >>> On 05.04.2017 12:19, Yann Ylavic wrote: >>>> O

Re: No timed lock on MacOS

iirc, that is like fdatasync... however, if someone has a test-case for me, I can run it. > On Apr 5, 2017, at 6:40 AM, Branko Čibej <br...@apache.org> wrote: > > On 04.04.2017 01:03, Jim Jagielski wrote: >> pthread_cond_timedwait() is available

fdatasync on OSX

Agreed. BTW check out https://github.com/gbrault/picoc/issues/145

Re: svn commit: r1790105 - in /apr/apr/branches/1.6.x: locks/unix/misc.c locks/unix/proc_mutex.c locks/unix/thread_mutex.c test/testlock.c

> On Apr 4, 2017, at 4:29 PM, Yann Ylavic wrote: > > > I'm not a big fan of the "sleep" fallback implementation. > Feel free to replace it with something better.

Re: No timed lock on MacOS

OK, I think I'm done with creating alternate timed implementation for all platforms that lack them... https://svn.apache.org/viewvc/apr/apr/branches/1.6.x/locks/unix/misc.c?revision=1790156=markup

Re: Default Linux mutex method

I think that "issue" is that all such options exist on all our (modern) platforms and we don't adjust them for specific OSs... We prefer sysv sems and pthread mutexes. > On Apr 4, 2017, at 6:27 AM, Nick Kew wrote: > > On Tue, 2017-04-04 at 10:07 +0200, Stefan Sperling wrote: >>

Re: No timed lock on MacOS

pthread_cond_timedwait() is available under OSX but neither PTHREAD_CONDATTR_SETPSHARED or pthread_condattr_setpshared are. Here's a version we can use for any that lack a real pthread_mutex_timedlock(): /* * A pthread_mutex_timedlock() impl for OSX/macOS, which lacks the * real thing. *

Re: No timed lock on MacOS

It looks like we can emulate it via: https://github.com/tinycthread/tinycthread/commit/1e8f9bba87959331e616d279dc54676e3a592799

Re: Default Linux mutex method

Considering the sad affair w/ pthread on OSX, I would recommend we stay w/ using sems.

Re: Default Linux mutex method

Of course, it depends on the number of threads, natch... > On Apr 3, 2017, at 2:07 PM, Jim Jagielski <j...@jagunet.com> wrote: > > Using: > >https://github.com/jimjag/benchmarks/blob/master/lock/lock_test.c > > under OSX/macOS, pthread_mutex_lock is much quicker

Re: Default Linux mutex method

Using: https://github.com/jimjag/benchmarks/blob/master/lock/lock_test.c under OSX/macOS, pthread_mutex_lock is much quicker. Which makes sense since sysv sems and posix sems do much more than simply "lock"

Re: No timed lock on MacOS

> On Apr 1, 2017, at 4:54 AM, Yann Ylavic wrote: > > On Fri, Mar 31, 2017 at 5:49 PM, Nick Kew wrote: >> Just (finally) got the toolchain up on the new macbook[1], so I’m >> testing there. Getting a failure in testprocmutex: there is no timedlock. >> >>

Re: No timed lock on MacOS

I *think* it's just supported right now for platforms that use pthread mutexes > On Mar 31, 2017, at 12:27 PM, Jim Jagielski <j...@jagunet.com> wrote: > > Nobody has added it yet in 1.6+ > > I've no idea what platforms are supported/implemented... > >> On Mar 31,

Re: No timed lock on MacOS

Nobody has added it yet in 1.6+ I've no idea what platforms are supported/implemented... > On Mar 31, 2017, at 11:49 AM, Nick Kew wrote: > > Just (finally) got the toolchain up on the new macbook[1], so I’m > testing there. Getting a failure in testprocmutex: there is no

Re: Default Linux mutex method

Reading the configure.in file, it looks like we are due for some updates for the 21st century: # See which lock mechanism we'll select by default on this system. # The last APR_DECIDE to execute sets the default. # At this stage, we match the ordering in Apache 1.3 # which is (highest to lowest):

Re: Default Linux mutex method

> On Mar 30, 2017, at 10:21 PM, William A Rowe Jr wrote: > > > SYSVSEM > PTHREAD in the code logic, so we are still using > sysv semaphores with all their defects over the choice of pthread > mutexes where both are supported on Linux. > Which is faster?

Re: Read scattered to gather send (was [too long]: httpd 2.4.25, mpm_event, ssl: segfaults)

This really belongs in dev@apr... Adding it now. If we are *really* drastically changing this core aspect of pool allocation, we should reconsider my thoughts related to more granular mutex related to anytime we alloc from a pool to allow for, if required/desired, full thread safety not just when

Re: APR pools, mutexes and thread safe allocations

Fair enuff... sounds like thread safe pools aren't something people are interested in, so I won't worry about it :) thx for the discussion!

Re: APR pools, mutexes and thread safe allocations

> > 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 that there is cross-thread issues. Thinking about 1.6 and especially apr 2.0, it

Re: APR pools, mutexes and thread safe allocations

> On Feb 20, 2017, at 10:58 AM, Yann Ylavic wrote: > > > So as Brane says, if one sets a mutex to the allocator of a pool > because (s)he wants pool_create/destroy() to be thread-safe, it does > not necessarily wants the same for palloc() and friends (e.g. the pool > is

Re: APR pools, mutexes and thread safe allocations

apr_pool_create_ex_debug(), yes. > On Feb 20, 2017, at 11:00 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > 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 a

Re: APR pools, mutexes and thread safe allocations

Please READ apr_pools.c... Search for '->mutex' > On Feb 20, 2017, at 10:58 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Mon, Feb 20, 2017 at 4:43 PM, Jim Jagielski <j...@apache.org> wrote: >> You are confusing pool mutexes with allocator mutexes... &

Re: APR pools, mutexes and thread safe allocations

> On Feb 20, 2017, at 10:26 AM, Branko Čibej wrote: > > > APR pools were designed with the assumption that separate threads will > always use separate pools whenever concurrent allocations are possible. > This assumption happens to fit pretty well with the >

Re: APR pools, mutexes and thread safe allocations

You are confusing pool mutexes with allocator mutexes... > On Feb 20, 2017, at 10:26 AM, Branko Čibej <br...@apache.org> wrote: > > On 20.02.2017 16:08, Jim Jagielski wrote: >> Again, this would ONLY happen if the underlying allocator has >> a mutex! > >

Re: APR pools, mutexes and thread safe allocations

I mean, of course, "has a *mutex*" > On Feb 20, 2017, at 10:39 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Again, I am only talking about those in which the allocator > has a pool... The allocator. Via apr_allocator_mutex_set(). > >> On Feb 20

Re: APR pools, mutexes and thread safe allocations

Again, I am only talking about those in which the allocator has a pool... The allocator. Via apr_allocator_mutex_set(). > On Feb 20, 2017, at 10:26 AM, Branko Čibej <br...@apache.org> wrote: > > On 20.02.2017 16:08, Jim Jagielski wrote: >> Again, this would ONLY hap

Re: APR pools, mutexes and thread safe allocations

Not with apr_palloc() or anything that calls apr_palloc (eg apr_pcalloc, et.al...) > On Feb 20, 2017, at 10:15 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > >> >> Am 20.02.2017 um 16:08 schrieb Jim Jagielski <j...@jagunet.com>: >

APR pools, mutexes and thread safe allocations

Again, this would ONLY happen if the underlying allocator has a mutex! > On Feb 20, 2017, at 10:06 AM, Branko Čibej <br...@apache.org> wrote: > > On 20.02.2017 15:55, Jim Jagielski wrote: >>> On Feb 20, 2017, at 9:51 AM, Stefan Eissing <stefan.eiss...@greenbytes.d

  1   2   3   4   5   6   7   >