Re: apr_dbm and concurrency

On 27.09.2023 14:37, Joe Orton wrote: On Mon, Sep 25, 2023 at 05:37:00PM +0200, Branko Čibej wrote: IIRC, Berkeley DB multi-process concurrency is managed through an on-disk "register" file external to the actual key/value store. The key/value store format is not affected by th

Re: apr_dbm and concurrency

On 25.09.2023 16:58, Joe Orton wrote: It is unspecified whether the apr_dbm.h interface is safe to use for multiple processes/threads having r/w access to a single database. Results appear to be: - sdbm, gdbm are safe - bdb, ndbm are not safe (Berkeley DB obviously can be used in a way which

Re: Xcode 12

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 at least it is throwing errors about -Werror,-Wimplicit-function-declaration, and not enabling IPv6: checking if APR supports

Re: apr-2 ... cleanup

^^ could be seen as too much, or not. I'm merely pointing out that we can keep some of the source-level compatibility without too much cost. > On Wed, May 13, 2020 at 4:28 AM Branko Čibej <mailto:br...@apache.org>> wrote: > > On 13.05.2020 10:41, Mladen Turk wrote: >

Re: apr-2 ... cleanup

On 13.05.2020 10:41, Mladen Turk wrote: > Hi, > > Related mostly to Windows port > > 1. Remove all those .dsp, .dsw .mak files from APR trunk >    None of them works for years. >    Replace all that with cmake > 2. Remove all _WIN32_WCE, APR_NOT_IN_WCE >    Just a bunch of code for Windows CE that

Re: Berkeley DB

On 02.12.2019 13:58, Filip Janus wrote: > Hello,  > I am package maintainer for Fedora and RHEL. I found out,  Your > application can be built with multiple databases(Berkeley DB , SQLite, > GDBM,...). I would like to ask if there can occur some problems with > compatibility after change(upgrade)

Re: Better choice for Linux semaphore than spinlock?

On Mon, 7 Oct 2019, 19:47 Doug Robinson, wrote: > Folks: > > I spoke with this user late last week. They stated that they can only get > approximately 400 parallel SVN operations before the "system time" consumes > all available CPU for an 8-core machine. Adding more cores won't help > because

Re: svn commit: r1862071 - in /apr/apr/trunk: file_io/os2/dir.c file_io/unix/dir.c file_io/win32/dir.c include/apr_file_info.h test/testdir.c

On 27.08.2019 11:25, Ruediger Pluem wrote: > > On 08/25/2019 04:04 PM, Branko Čibej wrote: >> On 24.08.2019 16:39, Ivan Zhakov wrote: >>> On Thu, 25 Jul 2019 at 15:58, Ivan Zhakov wrote: >>>> On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote: >>>>&g

Re: svn commit: r1862071 - in /apr/apr/trunk: file_io/os2/dir.c file_io/unix/dir.c file_io/win32/dir.c include/apr_file_info.h test/testdir.c

On 24.08.2019 16:39, Ivan Zhakov wrote: > On Thu, 25 Jul 2019 at 15:58, Ivan Zhakov wrote: >> On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote: >>> On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote: On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote: > They also make the existing old

Re: apr_stat() sometimes returning APR_INCOMPLETE (70008) on Windows 10

On 17.07.2019 10:18, Steve Hay wrote: > On Tue, 16 Jul 2019 at 18:31, Steve Hay wrote: >> On Tue, 16 Jul 2019 at 14:53, William A Rowe Jr wrote: >>> On Tue, Jul 16, 2019 at 8:10 AM Steve Hay >>> wrote: I'm in the process of preparing a new mod_perl release and have run into a few

Re: apr_pool_join() and APR_POOL_DEBUG

On 16.07.2019 23:18, Rainer Jung wrote: > I had some need for using APR_POOL_DEBUG today and ran into a > situation where pool lifetimes needed a hint using apr_pool_join(). > That is all documented and fine, except that I was surprised to see, > that apr_pool_join() doesn't work unless the

Re: svn commit: r1862071 - in /apr/apr/trunk: file_io/os2/dir.c file_io/unix/dir.c file_io/win32/dir.c include/apr_file_info.h test/testdir.c

On 02.07.2019 14:04, Joe Orton wrote: > On Tue, Jul 02, 2019 at 11:18:31AM +0100, Joe Orton wrote: >> Reading the win32 code a bit more, it is not constant-memory even with >> the buffer in apr_dir_t, because it can allocate from dir->pool (and >> even create cleanups!) in the more_finfo() call,

Re: svn commit: r1862071 - in /apr/apr/trunk: file_io/os2/dir.c file_io/unix/dir.c file_io/win32/dir.c include/apr_file_info.h test/testdir.c

On 02.07.2019 08:49, Joe Orton wrote: > On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote: >> On Tue, 25 Jun 2019 at 17:21, wrote: >> >>> Author: jorton >>> Date: Tue Jun 25 14:21:56 2019 >>> New Revision: 1862071 >>> >>> URL: http://svn.apache.org/viewvc?rev=1862071=rev >>> Log: >>>

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

On 11.06.2019 18:36, build...@apache.org wrote: > 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/275 > > Buildbot URL: https://ci.apache.org/ > > Buildslave

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

On 07.06.2019 21:58, William A Rowe Jr wrote: > I think the optimal way is to allocate a pair of apr thread-specific > wchar buffers in each thread's pool on startup, and use those > exclusively per-thread for wchar translations. We could be looking at > 64k/thread exclusively for name

Re: The case for apr-util-2.0

On 06.06.2019 09:29, Nick Kew wrote: >> On 6 Jun 2019, at 06:07, Mladen Turk wrote: >> >> I remember the days when apr was operating system abstraction layer, >> and apr-util was the bunch of platform independent code where one >> could eventually decide which key/value dbm (beside provided sdbm)

Re: [vote] Win32 Decision Point

On 24.04.2019 21:31, William A Rowe Jr wrote: > Some 17 years later we are at a crossroads, because the win32 code > is somewhat illegible and harder to maintain due to the ANSI-vs-UTF8, > Win9x-vs-NT code paths. > > NT won. The only remaining question is how many apr consumers are > leveraging

Re: Showstoppers to 1.7.0?

On 25.03.2019 07:17, Gregg Smith wrote: > Hi Yann, > > No, r1856096 doesn't help, but thanks. > > I think VS just doesn't like these arrays of unknown size. > >     usrc = (unsigned char[]){ }; >     utarget = (unsigned char[]){ }; This is not ANSI C. Visual Studio doesn't support C99 and later

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

On 22.02.2019 11:14, Yann Ylavic wrote: > On Fri, Feb 22, 2019 at 10:46 AM wrote: >> 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/189 > Hmm, something

Re: Allow SIGUSR2 with apr_signal_thread()

On 21.02.2019 19:11, Yann Ylavic wrote: > Hi, > > can we stop preventing APR users (e.g. httpd) from using SIGUSR2 > because of the way a tool worked 16 years ago (and probably doesn't > anymore)? No sarcasm here, just a question... > > IOW, may I: > Index: srclib/apr/threadproc/unix/signals.c >

Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD

On 17.01.2019 13:28, Stefan Sperling wrote: > On Thu, Jan 10, 2019 at 01:17:40AM +0100, Branko Čibej wrote: >> I get that part, my question was related to APR's configure setting the >> type of apr_off_t and its format specifier correctly on Linux but >> incorrectly on OpenBSD

Re: pool debugging and httpd HTTP/2

On 17.01.2019 15:05, Yann Ylavic wrote: > On Thu, Jan 17, 2019 at 2:55 PM Stefan Eissing > wrote: >> >>> Am 17.01.2019 um 14:04 schrieb Yann Ylavic : >>> >>> On Thu, Jan 17, 2019 at 1:56 PM Branko Čibej wrote: >>>> On 17.01.2019 13:55, Branko

Re: pool debugging and httpd HTTP/2

On 17.01.2019 13:11, Yann Ylavic wrote: > On Thu, Jan 17, 2019 at 1:09 PM Stefan Sperling wrote: >> On Thu, Jan 17, 2019 at 12:36:49PM +0100, Yann Ylavic wrote: >>> OK, so an APR only option like this? >> Yes, thank you, this looks great! >> I'll see about making OpenBSD's APR port use this

Re: pool debugging and httpd HTTP/2

On 17.01.2019 13:55, Branko Čibej wrote: > On 17.01.2019 13:21, Yann Ylavic wrote: >> On Thu, Jan 17, 2019 at 1:02 PM Yann Ylavic wrote: >>> On Thu, Jan 17, 2019 at 12:50 PM Branko Čibej wrote: >>>> Other than that, unlimited max-free is wrong in most cases, s

Re: pool debugging and httpd HTTP/2

On 17.01.2019 13:21, Yann Ylavic wrote: > On Thu, Jan 17, 2019 at 1:02 PM Yann Ylavic wrote: >> On Thu, Jan 17, 2019 at 12:50 PM Branko Čibej wrote: >>> Other than that, unlimited max-free is wrong in most cases, so why not >>> set the default to something sane instead

Re: pool debugging and httpd HTTP/2

On 17.01.2019 12:36, Yann Ylavic wrote: > On Thu, Jan 17, 2019 at 12:10 PM Stefan Sperling wrote: >> On Thu, Jan 17, 2019 at 12:04:37PM +0100, Yann Ylavic wrote: >>> On Tue, Jan 15, 2019 at 11:48 AM Stefan Sperling wrote: On Tue, Jan 15, 2019 at 11:19:24AM +0100, Stefan Eissing wrote: >

Re: pool debugging and httpd HTTP/2

On 15.01.2019 11:48, Stefan Sperling wrote: > On Tue, Jan 15, 2019 at 11:19:24AM +0100, Stefan Eissing wrote: >> Stefan: which DEBUG flags are "you" using in production for OpenBSD? I >> would like to run some h2 tests in exactly that setting... > We pass --enable-pool-debug=yes to the configure

Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD

On 09.01.2019 23:47, William A Rowe Jr wrote: > On Wed, Jan 9, 2019 at 3:26 PM Branko Čibej wrote: > >>> On Wed, Jan 9, 2019 at 9:38 AM Stefan Sperling wrote: >>> >>>> APR's configure script logic results in inconsistent type and format >>>> str

Re: Issue while accessing memory

On 23.11.2018 13:25, Nick Kew wrote: >> Please help me to solve this. > It looks as if your pool could be in charge of memory that something else > already freed. > > Possible causes of that lie outside the scope of what you posted. And > probably outside > the scope of APR. The most common

Re: New warnings on trunk in maintainer mode

On 17.11.2018 23:16, Branko Čibej wrote: > .../atomic/unix/builtins.c:71:53: warning: passing 'const void *' to > parameter of type 'void *' discards qualifiers > [-Wincompatible-pointer-types-discards-qualifiers] > return (void*) __sync_val_compare_and_swap(mem, cmp, wit

New warnings on trunk in maintainer mode

I see the following new-ish warnings on trunk, on macOS: .../jose/apr_jose_decode.c:21:14: warning: no previous prototype for function 'apr_jose_flatten' [-Wmissing-prototypes] apr_status_t apr_jose_flatten(apr_bucket_brigade *bb, apr_jose_text_t *in, 13 of these, the above is just a

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

On 17.11.2018 18:21, Branko Čibej wrote: > P.S.: I was a bit surprised that the Linux build slaves don't exercise > the test suite at all, just the build. Hah. My bad. The tests are run but that's not immediately obvious from the waterfall display. Fixed.

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

On 17.11.2018 18:21, Branko Čibej wrote: > On 17.11.2018 16:30, Nick Kew wrote: >>> On 17 Nov 2018, at 14:49, Branko Čibej wrote: >>> >>> This is a Python3 compatiblity bug in build/gen-build.py: >>> >>> UnicodeDecodeError: 'ascii' codec can'

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

On 17.11.2018 16:30, Nick Kew wrote: >> On 17 Nov 2018, at 14:49, Branko Čibej wrote: >> >> This is a Python3 compatiblity bug in build/gen-build.py: >> >> UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position >> 4731: ordinal not in range(1

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

On 17.11.2018 15:24, build...@apache.org wrote: > 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/177 > > Buildbot URL: https://ci.apache.org/ > > Buildslave

Re: r1842824

--- apr/apr/trunk/dbd/apr_dbd_odbc.c2018/10/04 15:03:24 1842823 +++ apr/apr/trunk/dbd/apr_dbd_odbc.c2018/10/04 15:13:54 1842824 @@ -689,7 +689,7 @@ if (!eos) { /* Create a new LOB bucket to append and append it */ -nxt =

Re: Init/de-init of aprfoo-1.so providers

On 27.07.2018 14:52, Yann Ylavic wrote: > On Thu, Jul 26, 2018 at 3:35 PM, Branko Čibej wrote: >> We've had constant and painful problems with this in Subversion, having >> to track down random crashes at process exit. We've implemented really >> horrible workarounds, and I'm

Re: Init/de-init of aprfoo-1.so providers

On 25.07.2018 17:46, William A Rowe Jr wrote: > Giving this problem some thought... > > If an aprfoo-1.so provider is linked to the libfoo.so library, and we > track the init state and perform it only once, it seems that apr > should never try to de-init or unload the .so provider for the >

Re: svn commit: r1835348 - in /apr/apr/trunk: CHANGES build.conf include/apr_json.h json/ json/apr_json.c json/apr_json_decode.c json/apr_json_encode.c test/Makefile.in test/abts_tests.h test/testjson

On 08.07.2018 16:23, Yann Ylavic wrote: >> + >> +if (treat_as_float) { >> +retval->type = APR_JSON_DOUBLE; >> +retval->value.dnumber = strtod(self->p, NULL); >> +} >> +else { >> +retval->type = APR_JSON_LONG; >> +retval->value.lnumber = strtol(self->p,

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

On 25.06.2018 23:16, Graham Leggett wrote: > On 25 Jun 2018, at 11:09 PM, build...@apache.org wrote: >> 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/109

Re: APR 2.0 RPMs Missing apr-util

On 08.05.2018 21:47, William Kimball Jr. wrote: > APR Developers, > > Hello!  I joined a little while back out of a need to add TLS > capabilities to apr_dbd_mysql > (https://bz.apache.org/bugzilla/show_bug.cgi?id=62342).  In my > exuberance to contribute and solve this problem quickly -- I have >

Re: [RFC] apr_array_find()

On 27.04.2018 21:23, 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 annoying. Iteration over an APR array is > easy, and very clear. There is basically no

Re: [RFC] apr_array_find()

On 27.04.2018 11:30, Nick Kew wrote: >> On 27 Apr 2018, at 03:37, Jim Riggs wrote: >> >> I am working on some httpd changes/features/ideas and have multiple needs to >> find items in an array. In httpd, we currently have these: >> >> AP_DECLARE(int) ap_array_str_index(const

Re: -q64 flag - gets in the way

On 08.12.2017 19:32, William A Rowe Jr wrote: > On Fri, Dec 8, 2017 at 5:49 AM, Branko Čibej <br...@apache.org> wrote: >> On 08.12.2017 12:35, Joe Orton wrote: >>> On Wed, Dec 06, 2017 at 10:06:22AM -0600, William A Rowe Jr wrote: >>>> They trust the

Re: -q64 flag - gets in the way

On 08.12.2017 12:35, Joe Orton wrote: > On Wed, Dec 06, 2017 at 10:06:22AM -0600, William A Rowe Jr wrote: >> They trust the compiler to do the right things, so there is no special >> sauce added to apr-config. Respective build flags land in >> /usr/lib/apr-1/build/ >> /usr/lib64/apr-1/build/ > We

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

On 04.11.2017 23:49, Yann Ylavic wrote: > On Sat, Nov 4, 2017 at 11:29 PM, Branko Čibej <br...@apache.org> wrote: >> On 04.11.2017 23:03, build...@apache.org wrote: >>> The Buildbot has detected a new failure on builder apr-x64-macosx-trunk >>> while buil

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

On 04.11.2017 23:03, build...@apache.org wrote: > 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/49 > > Buildbot URL: https://ci.apache.org/ > > Buildslave

Re: [VOTE] Release APR-UTIL 1.6.0

On 09.06.2017 15:07, 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 > [ ] Release apr-util 1.6.0 +1

Re: [VOTE] Release APR 1.6.2

On 09.06.2017 15:09, 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 > [ ] Release apr 1.6.2 +1 OS X

Re: [VOTE] Release APR-1.6.1 and APR-UTIL 1.6.0

On 08.06.2017 19:22, Dennis Clarke wrote: > How can I help? The average developer will have access to 32- or 64-bit Intel-architecture Linux variants. A few will bother to test on one of the *BSD flavours. Some of us have laptops running macOS. Windows development environments are widely

Re: 1.6.0 release candidates

On 17.04.2017 14:01, Rainer Jung wrote: > - ".svn" directory included, that's unusual Always 'svn export' the tag, not 'svn checkout' ...

Re: Et resurrexit tertia die.

On 13.04.2017 10:08, Nick Kew wrote: > On Mon, 2017-04-10 at 10:40 +0100, Nick Kew wrote: >> I think we've done most of 1.6.0, modulo a couple of questionmarks. >> I'm thinking it would be good to roll an actual release in time >> for the resurrection :) > Contemplating tagging tomorrow or

Re: buildbot success in on apr-x64-macosx-1.6.x

On 11.04.2017 22:18, Nick Kew wrote: > On Tue, 11 Apr 2017 20:03:34 +0200 > Branko Čibej <br...@apache.org> wrote: > > >>> APR trunk and 1.6.x on Ubunu and OSX >>> APR-Util 1.6.x on Ubuntu >> And now also APR-Util 1.6.x on OSX. > Also trunk? There's

Re: buildbot success in on apr-x64-macosx-1.6.x

On 11.04.2017 19:11, Branko Čibej wrote: > On 11.04.2017 16:50, Branko Čibej wrote: >> On 11.04.2017 16:45, build...@apache.org wrote: >>> The Buildbot has detected a restored build on builder apr-x64-macosx-1.6.x >>> while building . Full details are available at: &g

Re: buildbot success in on apr-x64-macosx-1.6.x

On 11.04.2017 16:50, Branko Čibej wrote: > On 11.04.2017 16:45, build...@apache.org wrote: >> The Buildbot has detected a restored build on builder apr-x64-macosx-1.6.x >> while building . Full details are available at: >> https://ci.apache.org/builders/apr-x64-

Re: buildbot success in on apr-x64-macosx-1.6.x

On 11.04.2017 16:45, build...@apache.org wrote: > The Buildbot has detected a restored build on builder apr-x64-macosx-1.6.x > while building . Full details are available at: > https://ci.apache.org/builders/apr-x64-macosx-1.6.x/builds/1 > > Buildbot URL: https://ci.apache.org/ > > Buildslave

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

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 > that means that it's "too late" and the expected result would > be a timeout, Timeout iff the lock can't be

Re: header file distribution bug

On 06.04.2017 22:00, Helmut K. C. Tessarek wrote: > There is a bug in how APR and APR-util are distributed. > > Some of the typical autotools defines made it into the current packages > and they interfere with one's own build process: > > one example (there are 5 different occurrences): > > In

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 06.04.2017 21:05, Yann Ylavic wrote: > On Thu, Apr 6, 2017 at 9:01 PM, Branko Čibej <br...@apache.org> wrote: >> On 06.04.2017 20:49, Yann Ylavic wrote: >>> On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski <j...@jagunet.com> wrote: >>>> apr-trunk (r179

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 06.04.2017 20:49, Yann Ylavic wrote: > On Thu, Apr 6, 2017 at 1:40 PM, Jim Jagielski wrote: >> apr-trunk (r1790379): >> % ./testall -v testprocmutex >> testprocmutex : -Line 189: Locks don't appear to work with timedlock >> -flock_timedlock() not implemented,/Line

Re: No timed lock on MacOS

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(), the > timeout variable is the actual wallclock time that the wait > expires (eg: now+5mins). But, from

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 05.04.2017 12:52, Branko Čibej wrote: > On 05.04.2017 12:50, Yann Ylavic wrote: >> On Wed, Apr 5, 2017 at 12:42 PM, 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...

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 05.04.2017 12:50, Yann Ylavic wrote: > On Wed, Apr 5, 2017 at 12:42 PM, 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:

Re: fdatasync on mac

On 05.04.2017 12:21, Branko Čibej wrote: > On 01.04.2017 03:22, Nick Kew wrote: >> fdatasync on Mac is a mess. What I’ve been hacking at is described in >> https://bugs.freedesktop.org/show_bug.cgi?id=74873 >> where they face the same issue. >> >> My inclinati

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 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: >>> On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski <j...@jagunet.com> wrote: >>>>> On

Re: No timed lock on MacOS

On 04.04.2017 01:03, Jim Jagielski wrote: > pthread_cond_timedwait() is available under OSX but neither > PTHREAD_CONDATTR_SETPSHARED or pthread_condattr_setpshared are. >From /usr/include/pthread.h on my mac: __OSX_AVAILABLE_STARTING(__MAC_10_4, __IPHONE_2_0) int

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 05.04.2017 12:19, Yann Ylavic wrote: > On Tue, Apr 4, 2017 at 10:57 PM, Jim Jagielski wrote: >>> 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

Re: fdatasync on mac

On 01.04.2017 03:22, Nick Kew wrote: > fdatasync on Mac is a mess. What I’ve been hacking at is described in > https://bugs.freedesktop.org/show_bug.cgi?id=74873 > where they face the same issue. > > My inclination is to steer clear of this mess. We can disable fdatasync on > mac > with a

By the way ...

r1790157 | jim | 2017-04-04 21:08:39 +0200 (Tue, 04 Apr 2017) | 2 lines the rest r1790149 | jim | 2017-04-04 19:47:30 +0200 (Tue, 04 Apr 2017) | 2

Re: fdatasync on mac

On 01.04.2017 03:22, Nick Kew wrote: > fdatasync on Mac is a mess. What I’ve been hacking at is described in > https://bugs.freedesktop.org/show_bug.cgi?id=74873 > where they face the same issue. > > My inclination is to steer clear of this mess. We can disable fdatasync on > mac > with a

Re: APR pools, mutexes and thread safe allocations

being slightly miffed off if their apps drastically slow down because they happen to be linked with a new version of APR. -- Brane >> On Feb 20, 2017, at 10:06 AM, Branko Čibej <br...@apache.org> wrote: >> >> On 20.02.2017 15:55, Jim Jagielski wrote: >>>> O

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

On 20.02.2017 15:55, Jim Jagielski wrote: >> On Feb 20, 2017, at 9:51 AM, Stefan Eissing >> wrote: >> >>> Am 20.02.2017 um 15:16 schrieb Jim Jagielski : >>> >>> The below got me thinking... >>> >>> Right now, the pool allocator mutex is only used

Re: [PATCH] deadlocking condition with APR_HAS_THREADS

y the bug is in the thread pool destructor since it does not behave correctly on one of the platforms it's supposed to work on. -- Brane > On Feb 8, 2017 4:30 PM, "Stefan" <luke1...@posteo.de> wrote: > >> On 2/2/2017 14:45, Branko Čibej wrote: >>> On 02.02.2017 1

Re: [PATCH] deadlocking condition with APR_HAS_THREADS

On 02.02.2017 13:30, Stefan Hett wrote: > On 2/2/2017 1:24 PM, Branko Čibej wrote: >> On 02.02.2017 12:49, Stefan Hett wrote: >>> On 2/2/2017 12:04 PM, Nick Kew wrote: >>>> On Wed, 2017-02-01 at 00:23 +0100, Stefan wrote: >>>>> Hi, >>>>

Re: [PATCH] deadlocking condition with APR_HAS_THREADS

On 02.02.2017 13:14, Stefan Hett wrote: > On 2/2/2017 12:52 PM, Branko Čibej wrote: >> On 01.02.2017 00:23, Stefan wrote: >>> Hi, >>> >>> the issue was discovered as part of tracing down a deadlock >>> condition in >>> an SVN test [1]. &

Re: [PATCH] deadlocking condition with APR_HAS_THREADS

On 02.02.2017 12:49, Stefan Hett wrote: > On 2/2/2017 12:04 PM, Nick Kew wrote: >> On Wed, 2017-02-01 at 00:23 +0100, Stefan wrote: >>> Hi, >>> >>> the issue was discovered as part of tracing down a deadlock >>> condition in >>> an SVN test [1]. >>> >>> As far as I understand it, the problem lies

Re: [PATCH] deadlocking condition with APR_HAS_THREADS

On 02.02.2017 12:04, Nick Kew wrote: > On Wed, 2017-02-01 at 00:23 +0100, Stefan wrote: >> Hi, >> >> the issue was discovered as part of tracing down a deadlock condition in >> an SVN test [1]. >> >> As far as I understand it, the problem lies in the C-standard not >> explicitly defining when a

Re: [PATCH] deadlocking condition with APR_HAS_THREADS

On 01.02.2017 00:23, Stefan wrote: > Hi, > > the issue was discovered as part of tracing down a deadlock condition in > an SVN test [1]. > > As far as I understand it, the problem lies in the C-standard not > explicitly defining when a function registered with atexit() is called > in the context

Re: apr-util error code

On 19.01.2017 18:30, Dirk-Willem van Gulik wrote: > On 19 Jan 2017, at 17:46, William A Rowe Jr wrote: > >> In 2.0 I'd like to see include/apu_error.h simply a stub to #include >> >> and track it all in one place. Will try to hold onto that though for >> my next round tuit.

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

2 utf8 logic is used for speed because it happens so often. > Slower alternatives always existed in the win32 API. Win9x and NT at least up to 4 did not have a UTF-8 "codepage". > And of course with FnA() it was always fun speculating if that call used > OEM CP or locale CP. :) :) &

Re: 1.6 apr/apr-util scope/timetable?

On 24.12.2016 18:56, Ivan Zhakov wrote: > CMakeCache.txt On 24 December 2016 at 13:36, Branko Čibej > <br...@apache.org> wrote: >> On 24.12.2016 08:23, Ivan Zhakov wrote: >>>>> CMake pollutes working copy with some unrelated files. >>>> ...it does?

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

On 22.12.2016 18:21, William A Rowe Jr wrote: > What I'd like us to consider is to rip out all FooFnA() ASCII calls, and > shift entirely to the Unicode mapping, perhaps with some support of > alternate operating charsets for the non-httpd consumer. Would like to hear > of folks deliberately

Re: 1.6 apr/apr-util scope/timetable?

On 24.12.2016 08:23, Ivan Zhakov wrote: >>> CMake pollutes working copy with some unrelated files. >> >> ...it does? I don't think I've had any pollution with my workflow, since >> CMake gives you the option to separate the build tree from the source tree. >> What files do you see showing up? >> >

Re: 1.6 apr/apr-util scope/timetable?

On 03.12.2016 16:40, William A Rowe Jr wrote: > I'm wondering, where do we go on trunk with 2.0 on Windows, > now that we can emit solution/project files from CMake, or just > straightforward .mak files? It insisting on a local install of CMake > all that much of a hassle for the Windows build

Re: apr_token_* conclusions

On 27.01.2016 20:56, William A Rowe Jr wrote: > On Wed, Jan 27, 2016 at 6:29 AM, Jim Jagielski <j...@jagunet.com > <mailto:j...@jagunet.com>> wrote: > > > > On Jan 27, 2016, at 4:44 AM, Branko Čibej <br...@apache.org > <mailto:br...@apache.org>&

Re: apr_token_* conclusions

On 27.01.2016 13:29, Jim Jagielski wrote: >> On Jan 27, 2016, at 4:44 AM, Branko Čibej <br...@apache.org> wrote: >> >> >> Hmph, it's concise, not confusing. Subversion's APIs expect all strings >> to be encoded in UTF-8, so the docstring can't just say >

Re: Mailing list semantics

On 28.01.2016 05:10, William A Rowe Jr wrote: > On Wed, Jan 27, 2016 at 10:08 PM, William A Rowe Jr > > wrote: > > > [] Keep reply-to-poster default reply semantics > [X] Change to reply-to-list default reply semantics > > > Easy choice, but

Re: apr_token_* conclusions

On 27.01.2016 01:17, William A Rowe Jr wrote: > On Tue, Jan 26, 2016 at 5:16 PM, Jim Jagielski > wrote: > > > > On Jan 26, 2016, at 4:39 PM, William A Rowe Jr > > wrote: > > > > On Tue,

Re: apr_token_* conclusions

On 01.12.2015 05:31, William A Rowe Jr wrote: > > That describes the 'token' use case, right? While MMX operands let > the clib devs play with 16-byte/dword/word units, we are principally > looking at very short strings. As soon as you do a 16 byte compare > w/delimiting the null byte, your

Re: apr_token_* conclusions

On 27.11.2015 15:59, Jim Jagielski wrote: >> On Nov 26, 2015, at 8:49 PM, Branko Čibej <br...@apache.org> wrote: >> >> In any case — I don't think anyone over at dev@s.a.o would object to APR >> including those functions. We actually have a number of other, heh,

Re: apr_token_* conclusions

On 26.11.2015 15:44, William A Rowe Jr wrote: > Better if I address this Q to svn folks at the APR project :) > On Nov 26, 2015 08:39, "William A Rowe Jr" wrote: > >> Sounds right... Actually a fusion between svn_cstring_* and several >> existing ap_ and apr_ functions would

Re: apr_token_* conclusions

On 26.11.2015 22:55, William A Rowe Jr wrote: > On Nov 26, 2015 11:03 AM, "Branko Čibej" <br...@apache.org> wrote: >> On 26.11.2015 15:44, William A Rowe Jr wrote: >>> Better if I address this Q to svn folks at the APR project :) >>> On Nov 26, 2015 08:3

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

On 21.11.2015 16:39, Yann Ylavic wrote: > On Sat, Nov 21, 2015 at 12:59 PM, Branko Čibej <br...@apache.org> wrote: >> On 21.11.2015 09:31, Graham Leggett wrote: >>> On 21 Nov 2015, at 12:11 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: >>> >>>&g

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

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 only one who wants to be strict about >> case-insensitive token string

Re: Optimization, modern C and APR 2.0 onwards

On 20.11.2015 19:53, Bert Huijben wrote: > +1 > > > > As long as we don’t require complete/100% C99 at this time. > > > > Microsoft only intends to implement the C99 subset that is also part of the > recent C++ specs (or just easy to do) in Visual Studio, and in most cases it > already does

Re: expat upgrade to 2.1.0

On 31.10.2015 18:48, Michael Felt wrote: > I would vote to make external expat the default and/or just remove > expat from apr. That's already been done on trunk (which will become 2.0) but is not something we can backport to the 1.x line, IMO. -- Brane

Re: Lua co-routines

On 26.09.2015 19:10, Jim Jagielski wrote: > I've been keen on libmill, which provides a golang-like > goroutine library. It seems that such functionality would > be cool for APR and APR-based apps (like serf and httpd). > > Then I started thinking: Lua also has a great coroutine impl > and it is

Re: Bug Reports for APR?

On 22.09.2015 05:03, Jeffrey Walton wrote: > Hi Everyone, > > I tried building on OSX but was unsuccessful. I'd like to inform the > devs of the issue, and provide config.log and the compiler error. > > Apache's APR page does not list a bug tracker > (https://apr.apache.org/). Searching for both

Re: Time for APR 2.0?

On 27.08.2015 05:46, William A. Rowe Jr. wrote: > Several years ago, we combined the functionality of apr and apr-util, > and that library no longer draws in sub-dependencies until specific > components are necessary (dbm providers, dbd providers, crypto > providers etc). > > It seems overtime

Re: Time for APR 2.0?

On 27.08.2015 18:49, Steffen wrote: Question for me is: what is the issue with dsw/dsp ? Dropping dsw/dsp is not the way to go, for years (VC8-VC14) I use dsw/dsp GUI to build httpd/apr for Apachelounge. Dropping dsw/dsp disconnects us from using the (very handy and productive) GUI and

  1   2   3   >