On 17/01/2022 05:53, William A Rowe Jr wrote:
On Fri, Dec 3, 2021 at 5:39 AM Mladen Turk wrote:
On 03/12/2021 12:35, Yann Ylavic wrote:
After all those CMakeLists changes, is building with cmake now
dedicated to Windows or does/can it work on *nixes too?
I never tried building with cmake
On 17/01/2022 05:58, William A Rowe Jr wrote:
On Wed, Dec 1, 2021 at 2:55 PM Mladen Turk wrote:
My proposal is to use 0x0603 (aka windows 8.1, windows server 2012r2)
Those are still supported until 2023
-1. Again, that simply limits us to never pick up "modern" tcp/ip symbol
On 17/01/2022 21:01, Paul Smedley wrote:
Hi Guys,
I'm still using the os2 APR code for Subversion and Apache2 - I'd like
to keep it. I'd even like to commit my patches at some point.
How realistic is that for apr/trunk, a.k.a 2.0.x?
I mean code in apr 1.x.x will still remain.
On 09/12/2021 16:27, Graham Leggett wrote:
On 08 Dec 2021, at 14:37, Nick Kew wrote:
If you can do that cleanly then great!
Should we draw a clean line under released branches,
so anything later than 1.7.x drops Netware, regardless
of whether it's a 1.8 or a 2.0?
For v2.0 and above it’s
On 08/12/2021 13:37, Nick Kew wrote:
On 7 Dec 2021, at 13:50, Mladen Turk wrote:
There are still bunch of Netware code
polluting win32 code in apr/trunk.
Since the Netware itself is discontinued for
quit some time, I wonder the effective purpose
of that code inside apr.
I propose
On 08/12/2021 08:33, Ruediger Pluem wrote:
I assumed this as a trunk/2.0 only proposal. Is my assumption wrong?
Yes, trunk only.
Just a simple copy/paste leftover cleanup, mostly for internals
Regards
--
^TM
Hi,
I plan to add support for Windows/arm64.
The current win32 code presumes x86 architecture
mostly for atomics and endianness.
Regards
--
^TM
Since apr-util API is now part of APR
I propose to rename all that legacy APU_FOO to APR_FOO
Regards
--
^TM
There are still bunch of Netware code
polluting win32 code in apr/trunk.
Since the Netware itself is discontinued for
quit some time, I wonder the effective purpose
of that code inside apr.
I propose to remove all that
#ifdef NETWARE from file_io/win32 and others,
since IMHO those are totally
On 03/12/2021 12:35, Yann Ylavic wrote:
After all those CMakeLists changes, is building with cmake now
dedicated to Windows or does/can it work on *nixes too?
I never tried building with cmake so far on *nix, so just wondering..
Even before the changes CMakeLists was windows only.
All
On 02/12/2021 13:21, Ivan Zhakov wrote:
> On Wed, 1 Dec 2021 at 21:26, Mladen Turk <mailto:mt...@apache.org>> wrote:
>
>
> So no uuidof used in recent Windows SDK.
>
> Btw Visual Studio 2008 support ended April 10, 2018 [1].
>
Sure, being abld to build with V
On 02/12/2021 13:21, Ivan Zhakov wrote:
On Wed, 1 Dec 2021 at 21:26, Mladen Turk <mailto:mt...@apache.org>> wrote:
So no uuidof used in recent Windows SDK.
Btw Visual Studio 2008 support ended April 10, 2018 [1].
Sure, being abld to build with VS2008 is not a problem.
Issues
On 01/12/2021 21:58, Eric Covener wrote:
On Wed, Dec 1, 2021 at 3:55 PM Mladen Turk wrote:
My proposal is to use 0x0603 (aka windows 8.1, windows server 2012r2)
Those are still supported until 2023
A little conservative for trunk but still reasonable to me
LOL :D
Well, after 12
#define NOUSER
On 01/12/2021 21:03, Mladen Turk wrote:
Well, according to my friend Bill
with r1881421 we have
#ifndef _WIN32_WINNT
-#define _WIN32_WINNT 0x0601
+#define _WIN32_WINNT 0x0A00
#endif
Regards
--
^TM
Well, according to my friend Bill
with r1881421 we have
#ifndef _WIN32_WINNT
-#define _WIN32_WINNT 0x0601
+#define _WIN32_WINNT 0x0A00
#endif
Well, at the end it makes sense, but hope
none of that code will be backported to 1.7.x
since it'll break everything.
But why you didn't delete all
So I tried few Microsoft Visual Studio versions...
#1 Visual Studio 2008
>cmake .. -G "Ninja" -DCMAKE_BUILD_TYPE=Release -DAPR_BUILD_TESTAPR=ON
-- The C compiler identification is MSVC 15.0.30729.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
>ninja
...
Ok, apr-2 sucks less now :D
After few patches there is some light on the horizon ..
> cmake .. -G "NMake Makefiles" -DAPU_HAVE_CRYPTO=ON -DAPR_BUILD_TESTAPR=ON
CMake Deprecation Warning at CMakeLists.txt:20 (CMAKE_MINIMUM_REQUIRED):
Compatibility with CMake < 2.8.12 will be removed from a
From their website ..
Apache Lounge has provided up-to-date Windows binaries and popular
third-party modules for more than 15 years. We have hundreds of
thousands of satisfied users: small and big companies as well as home
users. Always build with up to date dependencies and latest compilers,
Here is what I'm using ...
Drop this on top of apr/1.7.x branch
https://github.com/mturk/aprw/tree/main/apr/1.7.x
Open Visual Studio command prompt in that directory
> nmake
... Done
Also one can try
> nmake check
... Running Test suite
Simple and effective
On 30/11/2021 22:18, Mlade
BTW did anyone was able to compile trunk on netware or os2
There are bunch of those NWGNUmakefiles and netware subdirs
According to Wikipedia NetWare was discontinued in 2009
and OS/2 in 2001, so if anyone can explain why we have
those in trunk/apr-2 (that will be hopefully released one day).
n size
C:\Shared\Workplace\apache\apr\trunk\bbuild\buckets\apr_brigade.c(404):
error C2036: 'const void *': unknown size
C:\Shared\Workplace\apache\apr\trunk\bbuild\buckets\apr_brigade.c(411):
error C2036: 'const void *': unknown size
On 30/11/2021 22:18, Mladen Turk wrote:
Fighting with that f
Fighting with that for almost a week ...
Makefile.win
apr.dsp
apr.dsw
libapr.dsp
Also a simple search for *.dsp gives 17 additional matches
Eg.
nmake -f Makefile.win
'msdev' is not recognized as an internal or external command, operable
program or batch file.
Sure, since msdev.exe was part
It sucks
--
^TM
On 18/11/2021 11:14, Yann Ylavic wrote:
On Wed, Nov 17, 2021 at 8:10 PM Mladen Turk wrote:
This new patch does not blindly set nonblocking for the pipe-socket
(like r1894917) but adds a new ->socket boolean to Windows' struct
apr_file_t (similar to the existing ->pip
On 18/11/2021 11:14, Yann Ylavic wrote:
On Wed, Nov 17, 2021 at 8:10 PM Mladen Turk wrote:
If only a single thread can call apr_poll_drain_wakeup_pipe
it shoud be OK.
Calling apr_poll{set,cb}_poll() concurrently on the same pollset is
quite undefined behaviour with our implementation(s), so
On 17/11/2021 18:50, Yann Ylavic wrote:
On Wed, Nov 17, 2021 at 5:19 PM Mladen Turk wrote:
On 17/11/2021 16:53, Yann Ylavic wrote:
apr_poll_drain_wakeup_pipe() should consume each byte sent on the pipe
corresponding to a wakeup_set flip.
Yes, its basically just one byte and one call
Attached a patch that fixes those huge writes to drain pipe
Tested on cetos8, all test pass
On 17/11/2021 08:08, Ruediger Pluem wrote:
On 11/17/21 2:39 AM, Mladen Turk wrote:
On 16/11/2021 12:00, Yann Ylavic wrote:
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
Otherwise I'll
On 17/11/2021 08:08, Ruediger Pluem wrote:
On 11/17/21 2:39 AM, Mladen Turk wrote:
On 16/11/2021 12:00, Yann Ylavic wrote:
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
Otherwise I'll revert because I have no way to test it, but I think
that apr_poll_drain_wakeup_pipe() might
On 16/11/2021 12:00, Yann Ylavic wrote:
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
Otherwise I'll revert because I have no way to test it, but I think
that apr_poll_drain_wakeup_pipe() might block on Windows for the same
reason as r1894914 for platforms with poll()able pipes.
On 16/11/2021 12:00, Yann Ylavic wrote:
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
Otherwise I'll revert because I have no way to test it, but I think
that apr_poll_drain_wakeup_pipe() might block on Windows for the same
reason as r1894914 for platforms with poll()able pipes.
On 3/7/21 1:26 PM, Frykenvall, Per wrote:
Dear APR developers,
I've studied the source code of apr_proc_create and found out that given a .bat
script on Windows, the command is executed using CMD.EXE /C even when using
APR_PROGRAM_ENV:
On 14/05/2020 10:48, Steffen wrote:
On Wednesday 13/05/2020 at 10:41, Mladen Turk wrote:
Hi,
Please tell me what is the exact issue with dsw/dsp/mak.
Hard to work with and maintain, but if someone
founds it usabe, then fine.
When I look at the cmake in current HTTP/Apr GA, it is not good
On 13/05/2020 22:08, Gregg Smith wrote:
#1, I think this may be your opinion but not so much mine. No, .mak/defs are
not in trunk but they never have been and they have been added at fork to
currently all the 1.0 series. And unless I'm mistaken, 1.7 was not that long
ago.
Well, I'll try
On 13/05/2020 21:04, Ivan Zhakov wrote:
On Wed, 13 May 2020 at 11:41, Mladen Turk mailto:mt...@apache.org>> wrote:
1. Remove all those .dsp, .dsw .mak files from APR trunk
None of them works for years.
Not as I objection, but .mak files work for me.
Not for me. .mak
On 13/05/2020 11:28, Branko Čibej wrote:
On 13.05.2020 10:41, Mladen Turk wrote:
1. Remove all APU_XXX references
Since the apr-util is apr
remove all APU_XXX defines and API
This will cause any coded that's upgrading from apr/apu 1.x to apr 2.x
and uses those symbols to break. That's
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
never worked, and no chance it will compile with
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)
and bundled subset of expat. And then there was apr-iconv
When asking why can't we put some of
On 04/04/2012 04:46 PM, William A. Rowe Jr. wrote:
On 4/4/2012 9:34 AM, mt...@apache.org wrote:
Author: mturk
Date: Wed Apr 4 14:34:44 2012
New Revision: 1309410
Can we please declare all prior to 1.4 branch, excepting 0.9, dead?
Fine with me.
What about 1.5.x
Is there any plan to
On 03/01/2012 01:19 PM, Jeff Trawick wrote:
Regardless of the APR_SIZEOF_VOIDP issue, it should be _WIN64 in the
.c/.h code. I'll commit that. I guess the attribution to use is the
e-mail address in bug 49155.
_WIN64 is defined by cl.exe (same as WIN32/_WIN32)
WIN64 should be defined by
On 12/14/2011 04:25 AM, William A. Rowe Jr. wrote:
Reposting for Graham's benefit, who likely skimmed over this;
On 12/11/2011 1:49 PM, Rainer Jung wrote:
- Windows Build system:
- all *.dep and *.mak files are missing
- in test/testutildll.dsp the probably obsolete string NT is
On 12/14/2011 03:14 PM, Rainer Jung wrote:
On 14.12.2011 11:09, Mladen Turk wrote:
On 12/14/2011 04:25 AM, William A. Rowe Jr. wrote:
Reposting for Graham's benefit, who likely skimmed over this;
On 12/11/2011 1:49 PM, Rainer Jung wrote:
- Windows Build system:
- all *.dep and *.mak files
On 12/08/2011 12:25 AM, Graham Leggett wrote:
Tarballs/zipballs are at
http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
+/-1
[X ] Release apr-util 1.4.1 as GA
+1
Regards
--
^TM
On 12/08/2011 05:15 PM, Graham Leggett wrote:
On 08 Dec 2011, at 5:21 PM, mt...@apache.org wrote:
Author: mturk
Date: Thu Dec 8 15:21:21 2011
New Revision: 1211930
URL: http://svn.apache.org/viewvc?rev=1211930view=rev
Log:
Fix broken macro. driver.init takes three params and we don't have
Hi,
Fixed the 1.4.x branch win32 crypto API and modules
(Mostly by adding missing build files and one API bug)
They can now compile using Mozilla's xulrunner SDK and any OpenSSSL SDK.
We could reconsider re-tagging 1.4.0 (or just making 1.4.1)
Regards
--
^TM
On 12/07/2011 07:17 PM, Roy T. Fielding wrote:
Just to confirm, this only gets compiled if the user has added a --with
option specific to nss, right? Otherwise it impacts our license.
Actually it's
editing apu.hw and setting APU_HAVE_CRYPTO to 1, and then
nmake -f Makefile.win
On 12/07/2011 09:32 PM, William A. Rowe Jr. wrote:
On 12/7/2011 10:54 AM, Mladen Turk wrote:
On 12/07/2011 07:17 PM, Roy T. Fielding wrote:
Just to confirm, this only gets compiled if the user has added a --with
option specific to nss, right? Otherwise it impacts our license.
Actually it's
On 12/06/2011 02:23 AM, Graham Leggett wrote:
Tarballs/zipballs are at http://apr.apache.org/dev/dist/.
+/-1
[+1] Release apr-util 1.4.0 as GA
Signatures OK
Tested on Linux and Winows
Regards
--
^TM
On 12/06/2011 01:57 PM, Mladen Turk wrote:
On 12/06/2011 02:23 AM, Graham Leggett wrote:
Tarballs/zipballs are at http://apr.apache.org/dev/dist/.
+/-1
[+1] Release apr-util 1.4.0 as GA
Signatures OK
Tested on Linux and Winows
I'm changing my vote to -1 since windows crypto API
On 12/07/2011 12:39 AM, Igor Galić wrote:
- Original Message -
-0.5 non-binding of course
Seems the purpose was to get apr_crypto. On Windows it's not built,
even
with APU_HAVE_CRYPTO set to 1 since apr_crypto.c is not included in
the
project for either static lib or dll.
Once that
Hi,
Anyone can explain the purpose of add_ring in Solaris
port.c and its usage during pollset_add/pollset_wait
Current behavior is different from other implementations
in such way that adding faulty sockets (e.g. shutdown)
to the pollset behaves randomly depending on the state at
which
On 07/06/2011 02:52 PM, Eric van der Maarel wrote:
Hi,
Recently I proposed a fix for the select version of apr_pollset_poll
implementation, that prevents cpu going to 100% when all clients have
disconnected
(http://mail-archives.apache.org/mod_mbox/apr-dev/201106.mbox/browser). It
actually
On 04/28/2011 03:32 PM, Jeff Trawick wrote:
On Thu, Apr 28, 2011 at 9:17 AM, Richard van der Laan
richard.vanderl...@luminis.eu wrote:
Hi,
Anybody with a similar experience and/or solution?
This is what you need, right? (sorry, in a rush at the moment)
[+ 1] Release apr 0.9.19 as GA
Tested on linux and win32
Regards
--
^TM
[+1] Release apr-util 0.9.19 as GA
Tested on linux and win32
Regards
--
^TM
On 10/12/2010 12:45 PM, to...@tuxteam.de wrote:
Thus, it would seem safe to call apr_initialize from each extension -
I'd just have to make sure that the calls are balanced. Is that right?
Exactly. You can call it as many times as you wish.
Making sure the number of calls match.
Another
On 08/26/2010 12:06 PM, Jeff Trawick wrote:
On Thu, Aug 26, 2010 at 1:02 AM, mt...@apache.org mailto:mt...@apache.org
wrote:
Author: mturk
Date: Thu Aug 26 05:02:33 2010
New Revision: 989443
URL: http://svn.apache.org/viewvc?rev=989443view=rev
Hi,
pollset provider code has been back ported from trunk
like a year ago, but the Win32 port was partially backported
(lacking the WSAPoll provider support)
I plan to backport that from the trunk.
Regards
--
^TM
On 08/23/2010 04:53 PM, Christian K. wrote:
Hello,
In this application I want to write a dbm file, to use for HTTPD
authentication. Since I do not want to make any assumption on the
initialization state of apr I would like to repeatedly initialize and
terminate apr.
IMHO this is API misuse.
Hi,
Will you do something about that or do I have
to make the official -1?
So far you didn't even consider to reply which
is I presume caused by the email noise.
On 04/04/2010 05:58 PM, Mladen Turk wrote:
On 04/03/2010 05:43 PM, b...@apache.org wrote:
Author: bjh
Date: Sat Apr 3 15:43:00
On 04/07/2010 01:31 PM, William A. Rowe Jr. wrote:
By rights, we should be moving apr_support.h out of include/, that was a first
mistake. I have the same understanding as you, Mladen, but the authors of the
httpd mod_reqtimeout seem to be reaching their fingers into this header.
If that's
On 04/07/2010 03:40 PM, Brian Havard wrote:
I'm not sure why but I didn't get your original email quoted below.
I added the APR_DECLARE because I can't build httpd trunk without it.
apr_wait_for_io_or_timeout() is used in 2 places in httpd. The one
causing me trouble is in mod_reqtimeout.c. The
On 03/09/2010 03:42 PM, jfcl...@apache.org wrote:
Author: jfclere
Date: Tue Mar 9 14:42:23 2010
New Revision: 920897
URL: http://svn.apache.org/viewvc?rev=920897view=rev
Log:
typos? Otherwise it won't compile.
Since APR 2 won't support Win95, IMO the entire
WIN_OS_IS_ANSI and UNICODE_FS
On 02/16/2010 06:07 PM, jfcl...@apache.org wrote:
Log:
Make sure we don't leak file descriptors.
if (new_m-shmkey == (key_t)-1) {
+apr_file_close(file);
return errno;
}
File will be closed when the pool gets destroyed.
Closing here has little
Hi,
I just noticed a wired case where poll returns an signalled descriptor
event with revents == 0.
This can happen regularly with pipes if you create two separate pipes
for stdout and stderr for redirected process.
E.g. redirecting '/bin/sh ls' with two set of pipes and doing poll on
both
On 18/10/09 19:57, Jeff Trawick wrote:
There is no consensus yet on the scope of what has to be addressed
(distinct from whether the project or the packager should address it).
The discussion in the earlier commit thread needs to be carried to
its conclusion.
What about simply making
On 19/10/09 13:28, Jeff Trawick wrote:
What about simply making apr.h/apu.h as a stubs
for apr-$CPU.h
(I don't yet see how we can make a useful contribution on other
aspects of multi-architecture support -- fat binary or multiple
bin/lib/build directories or )
The bottom line is
On 19/10/09 14:43, Jeff Trawick wrote:
Anyhow, APR currently lacks the configure options for at
least specifying data model (using CFLAGS=-m32 ./configure
is a little bit awkward and nowhere documented)
BTW, you have to specify the arch option in CC for all the
apr-n-config stuff to work
On 19/10/09 15:41, Jeff Trawick wrote:
Perhaps I'm out in left field, but I anticipate that packagers will
determine the appropriate arch flags based on exactly what hardware
they support, and use that across a number of open source packages.
Sure.
(Should foo-32 support any 32-bit foo
On 19/10/09 16:37, William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Anyhow, APR currently lacks the configure options for at
least specifying data model (using CFLAGS=-m32 ./configure
is a little bit awkward and nowhere documented)
Resolving that would certainly be one small step helping
On 16/10/09 10:26, Yuri V. Vishnevskiy wrote:
Dear developers,
For some reason in my program I need two file handlers of stdout stream.
Could anybody try to reproduce this problem?
Crash happens on windows as well, so it might be a real
thing.
If you need two file objects perhaps a dup could
On 16/10/09 10:39, Joe Orton wrote:
It seems like reasonable behaviour that the second apr_file_close() call
should fail, though it certainly isn't obvious from reading the docs.
How else do you expect it to behave? You cannot close an fd twice.
I suppose it shouldn't crash the apr.
IMO
On 16/10/09 11:01, Joe Orton wrote:
I think the reporter meant fail when they said crash.
Dunno what he meant but I confirmed last week's almost exact
report that crashes (really) windows.
I don't see any reason why it would crash on Unix: the first call to
apr_file_close() will set
On 16/10/09 11:21, Joe Orton wrote:
On Fri, Oct 16, 2009 at 11:17:17AM +0200, Mladen Turk wrote:
each invocation to apr_file_open_stdout creates a new apr_file_t so
each fd-filedes has a value of STDOUT_FILENO.
This is the same as calling:
close(1);
close(1);
Oh, good point. This is rather
On 16/10/09 16:41, Jonathan Leffler wrote:
On Fri, Oct 16, 2009 at 7:31 AM, Yuri V. Vishnevskiy
yuri.vishnevs...@gmail.com mailto:yuri.vishnevs...@gmail.com wrote:
This is related with another my problem. If I close stdout by
apr_file_close, then the standard printf and fprintf(stdout,
On 16/10/09 16:56, William A. Rowe, Jr. wrote:
Mladen Turk wrote:
What 99% users would need is apr_file_attach_std* set of functions
giving the apr_file_t capable API without destroying the system
std streams.
And we should probably protect the sigleton apr_file_open_std*
against multiple
Just an update from the conversation I had with Yuri.
He confirmed that the APR crashes if build with VS2008.
(both debug and release version of msvcrt90(d).dll)
Now looking at the MSVCRT source for _close, I suspect
it crashes with VS2005 as well.
Since it doesn't crash if linked to msvcrt.dll
Hi,
I suppose Bill will give some more insight into this
cause it's only win related.
I came into edge case where utf8_to_unicode_path fails
for apr_stat on NT pipes.
NT pipes have maximum name length of 256 chars, and
utf8_to_unicode_path starts mangling paths longer
then 248 chars.
code from
On 10/08/09 17:15, William A. Rowe, Jr. wrote:
Mladen Turk wrote:
IMHO every module should have an configure option to either
build statically or as DSO, not as right now (all or none)
-1... yes it might be present, but it is a waste of process resource
to have a fixed binding for the 90
On 09/08/09 03:56, Guenter Knauf wrote:
so this means for the NetWare build: either have set APU_DSO_BUILD=0 in
order to build LDAP static and then no DBD driver at all, or have set
APU_DSO_BUILD=1 and be forced to build LDAP as DSO.
If we have already an own define APU_DSO_LDAP_BUILD - why
On 17/07/09 05:49, Ryan Phillips wrote:
Michael Spieglem...@nauticaltech.com said:
It doesn't look like the apr_memcache_* API has support for local unix
sockets (instead of TCP). I wanted to look into hacking this together
myself, but I'm having a hard time finding any information on using
Jack Andrews wrote:
hi,
i want to detect IO on a child process stdio as well
as a socket from elsewhere. ie. i want a select()
on /windows/.
is it possible with APR? or do i have to hack around?
It's not possible with APR, however you can make a hack
if you know its stdin (or stdout,
rpl...@apache.org wrote:
Author: rpluem
Date: Fri Apr 3 13:13:26 2009
New Revision: 761662
URL: http://svn.apache.org/viewvc?rev=761662view=rev
Log:
* Correctly setup size field for the final_blocks field.
Modified:
apr/apr/trunk/memory/unix/apr_pools.c
Modified:
URL: http://svn.apache.org/viewvc?rev=761692view=rev
Log:
Make final_block dynamic.
It is used only so we can create our mutex that will survive pool_clear
No mater what you do the new implementation simply sucks
when compared to the old one.
The performance is 2 to 20+ times! slower
Ruediger Pluem wrote:
On 04/03/2009 04:31 PM, mt...@apache.org wrote:
Author: mturk
Date: Fri Apr 3 14:31:16 2009
New Revision: 761692
URL: http://svn.apache.org/viewvc?rev=761692view=rev
Log:
Make final_block dynamic.
It is used only so we can create our mutex that will survive
Mladen Turk wrote:
So, it's been proven that the new apr pool
doesn't perform well except on some obscure platforms
with third-party libraries.
Just did some more profiling on the new apr-pool code
inside httpd. I've simply
#undef malloc
#undef calloc
and add size and number of call counters
So, it's been proven that the new apr pool
doesn't perform well except on some obscure platforms
with third-party libraries.
Further more the new pool broke the API since Paul
decided he doesn't need the unmanaged pools ;)
Since there were absolutely nothing wrong with the old
code can we have
Sander Striker wrote:
... and yes, can we get rid of the POOL_DEBUG.
It totally breaks the apr concept of a clean API,
and doubles the pool code without (at least to me)
any good reason.
Darn, you almost had me there (April Fools!). Just in case you were
being serious, the pool debug code
Jim Jagielski wrote:
On Mar 26, 2009, at 7:51 PM, Justin Erenkrantz wrote:
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental waste of time.
If we can't beat the old system by COB tomorrow consistently, then I
think we can simply revert it or we
Just did some quick bench of the current trunk,
and the results are not very much encouraging.
static void test_performance(abts_case *tc, void *data)
{
apr_status_t rv;
int i;
void *m;
apr_time_t end, now = apr_time_now();
for (i = 0; i 100; i++) {
apr_pool_t
Mladen Turk wrote:
Just did some quick bench of the current trunk,
and the results are not very much encouraging.
Inner loops are even worse.
Calling 1 x 32 bytes allocations
is more then 10 times slower.
This takes less then a second on my box to finish
with apr 1.4 and 11 seconds
Paul Querna wrote:
I believe Platforms that have no one around to support should be
removed (svn history will always be there, and they can always be
rebuilt). In APR especially the operating systems with different
implementations, I would prefer to just remove them if no one wants to
keep
Paul Querna wrote:
Attached is a program that you can use for this.
please upgrade to trunk, i've eliminated some callocs, and switched
them to malloc where possible.
compile with:
gcc -o pspeed13 `apr-1-config --link-ld --cppflags--cflags
--includes--ldflags--libs `
Paul Querna wrote:
Attached is a program that you can use for this.
please upgrade to trunk, i've eliminated some callocs, and switched
them to malloc where possible.
compile with:
gcc -o pspeed13 `apr-1-config --link-ld --cppflags--cflags
--includes--ldflags--libs `
Joe Orton wrote:
On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
What's the point?
The null hypothesis is: modern malloc implementations do exactly the
same optimisation work (e.g. maintaining freelists) that we duplicate in
APR pools. By avoiding that duplication, and relying
Paul Querna wrote:
On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej br...@xbc.nu wrote:
We have JNI bindings for Subversion, which uses APR, whose packaging and
compilation options we don't control. *boom*
That is only talking about loading tcmalloc using the normal library.
you can compile
Ruediger Pluem wrote:
On 24.03.2009 11:21, Paul Querna wrote:
Hi,
At ApacheCon, we have had a discussion about APR 2.x and APR-Util.
In the short term, we would like to merge the two libraries, into one
monolithic giant APR 2 library.
In the long term, we would like to split out things that
Ruediger Pluem wrote:
On 25.03.2009 08:45, Mladen Turk wrote:
Ruediger Pluem wrote:
On 24.03.2009 11:21, Paul Querna wrote:
Hi,
At ApacheCon, we have had a discussion about APR 2.x and APR-Util.
In the short term, we would like to merge the two libraries, into one
monolithic giant APR 2
Ruediger Pluem wrote:
And I think the expat is missing from xml.
So the --with-expat=builtin doesn't work
Bundled expat was removed in r757820. So it cannot work anymore.
So what's the solution for Windows?
How did we compensate the removal of the bundled pcre in httpd on trunk?
We
Joe Orton wrote:
On Wed, Mar 25, 2009 at 08:45:37AM +0100, Mladen Turk wrote:
And I think the expat is missing from xml.
So the --with-expat=builtin doesn't work
If you unpack a tarball of expat and plonk it at xml/expat it should
still work; none of the build infrastructure has been removed
Paul Querna wrote:
On Wed, Mar 25, 2009 at 1:17 PM, Mladen Turk mt...@apache.org wrote:
Joe Orton wrote:
On Wed, Mar 25, 2009 at 08:45:37AM +0100, Mladen Turk wrote:
And I think the expat is missing from xml.
So the --with-expat=builtin doesn't work
If you unpack a tarball of expat and plonk
1 - 100 of 416 matches
Mail list logo
