[STATUS] (apr) Wed Oct 13 23:45:18 EDT 2004
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*- Last modified at [$Date: 2004/09/02 03:49:03 $] Releases: Standalone 1.0.0 : released September 1, 2004 0.9.3 : tagged March 30, 2003 0.9.2 : released March 22, 2003 0.9.1 : released September 11, 2002 0.9.0 : released August 28, 2002 Bundled with httpd 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 RELEASE 0.9 SHOWSTOPPERS: RELEASE 1.0 SHOWSTOPPERS: CURRENT VOTES: CURRENT test/testall -v EXCEPTIONS: Please add any platform anomilies to the following exception list. * various tests fail on Unix in VPATH builds. * 'testipsub' will tickle an Solaris 8 getaddrinfo() IPv6 bug, causing the test to hang. Configure with --disable-ipv6 if using an unpatched Solaris 8 installation. * The 'testdso' tests will not work if configured with --disable-shared since the loadable modules cannot be built. * 'testdso' fails on older versions of OpenBSD due to dlsym(NULL, ...) segfaulting. * BUG: Win32 fails test in File Info: test_stat_eq_finfo apr_stat and apr_getfileinfo differ in protection ... wrowe guesses that we are checking the handle objects' permissions rather than the filesystem objects' permissions. * Win32 Not Implemented tests Pipes: set_timeout/read_write; can't timeout blocking pipes Socket Creation: tcp6_socket and udp6_socket (at least by default) Socket Options: corkable: TCP isn't corkable Users: username: Groups from apr_uid_get not implemented RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Someone needs to port testucs to Unix. Right now it only works on Windows. * The return type of a thread function (void *) is inconsistent with the type used in apr_thread_exit()/apr_thread_join() (apr_status_t). The thread function's return type should be changed to apr_status_t so that a return from the thread main function has the same effect as apr_thread_exit(). See Message-Id: [EMAIL PROTECTED] for thread discussing this. +1: BrianH, Aaron, david, jerenkrantz Status: Will Rowe was working on this. * Need some architecture/OS specific versions of the atomic operations. progress: generic, solaris Sparc, FreeBSD5, linux, and OS/390 done need: AIX, AS400, HPUX * The new lock API is a full replacement for the old API, but is not yet complete on all platforms. Components that are incomplete or missing include: Netware: apr_proc_mutex_*() (Is proc_mutex unnecessary on Netware?) * proc_mutex is not necessary on NetWare since the OS does not support processes. The proc_mutex APIs actually redirect to the thread_mutex APIs. (bnicholes) OS/2: apr_thread_cond_*(), apr_proc_mutex_*() Less critical components that we may wish to add at some point: Beos: apr_thread_rwlock_try*lock() apr_proc_mutex_trylock() Unix: apr_thread_rwlock_*() for platforms w/o rwlocks in pthread Win32: apr_thread_cond_timedwait(), apr_proc_mutex_*() (Is proc_mutex unnecessary on Win32?) * Need to contemplate apr_strftime... platforms vary. OtherBill suggested this solution (but has no time to implement): Document our list of 'supported' escapes. Run some autoconf/m4 magic against the complete list we support. Move the strftime re-implementation from time/win32 to time/unix. Add some APR_HAVE_STRFTIME magic to use the system fn, or fail over to time/unix/strftime.c. Message-ID: [EMAIL PROTECTED] * Using reentrant libraries with non-threaded APR - Anecdotal evidence exists that suggests it is bad to mix reentrant and non-reentrant libraries and therefore we should always use the reentrant versions. - Unfortunately, on some platforms (AIX 4.2.1) defining the reentrant flag (-D_THREAD_SAFE) causes builds to fail, and so one would expect --disable-threads to fix this. Although this has been fixed for that particular version of AIX, it may be useful to only enable the reentrant versions when threads are enabled. How will we deal with this issue once APR becomes a standalone library? It is perfectly legitimate to have apps needing both versions (threaded/reentrant and non-threaded/non-reentrant) on the same machine. * Pools debugging - Find a way to do check if a pool is used
[STATUS] (apr-util) Wed Oct 13 23:45:25 EDT 2004
APRUTIL LIBRARY STATUS: -*-text-*- Last modified at [$Date: 2004/06/30 11:44:19 $] Release: 1.0.0 rc2 : Tagged June 30th 2004(APU_1_0_RC2) 1.0.0 rc1 : Tagged June 2004 (APU_1_0_RC1) 0.9.3 : Tagged March 30, 2002 0.9.2 : Released March 22, 2002 (alpha) 0.9.1 : Released September 11, 2002 (alpha) 0.9.0 : Not released 2.0a9 : released December 12, 2000 RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Solaris's Sun Freeware (sfw) package has a busted gcc/ld setup. This gcc passes -L/opt/sfw/lib to /usr/ccs/bin/ld, but does not pass -R. Therefore, when trying to run the code using a library from /opt/sfw/lib (say, libdb), the run-time linker will not look in /opt/sfw/lib and the program will die. Status: Workaround is to add -R/opt/sfw/lib to LDFLAGS. Should check latest sfw package set and see if Sun may have fixed this. * GDBM usage of errno is not-thread-safe. Fix. Other bugs that need fixing: Other features that need writing: * possibly move test/testdbm* to util/dbu Justin says: Do we still want to do this? testdate is now in test. Status: Greg +1 (volunteers) Documentation that needs writing: * API documentation Status: * doc the lifetimes of apr_dbm return values Available Patches: Open Issues:
RE: Pools, C++, and Exceptions Best Practices
-Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED] Subject: Re: Pools, C++, and Exceptions Best Practices You'll be eating through your available memory at a pretty quick rate this way. Each pool preallocates 8k. In your case this means that every object you instantiate, you allocate 8k. Does APR allocate 8k per root memory pool, or for subpool? When I destroy a subpool does it recycle the memory? So, for example, how much memory (roughly) would the following code allocate: # apr_pool_t *root, *sub0, *sub1; # apr_pool_create( root, 0 ); # apr_pool_create( sub0, root ); # apr_pool_destroy( sub0 ); # apr_pool_create( sub1, root ); Basically, does a pool grow infinitely until it's destroyed, or does it recycle subpool memory? -david
RE: Pools, C++, and Exceptions Best Practices
On Thu, 2004-10-14 at 08:08, David Barrett wrote: -Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED] Subject: Re: Pools, C++, and Exceptions Best Practices You'll be eating through your available memory at a pretty quick rate this way. Each pool preallocates 8k. In your case this means that every object you instantiate, you allocate 8k. Does APR allocate 8k per root memory pool, or for subpool? Per pool, be it a root pool or a subpool. When I destroy a subpool does it recycle the memory? Yes. So, for example, how much memory (roughly) would the following code allocate: # apr_pool_t *root, *sub0, *sub1; # apr_pool_create( root, 0 ); # apr_pool_create( sub0, root ); # apr_pool_destroy( sub0 ); # apr_pool_create( sub1, root ); 16k. Basically, does a pool grow infinitely until it's destroyed, or does it recycle subpool memory? When a pool is cleared all of it's allocated memory except an 8k block is returned to the pools allocator. When a pool is destroyed, that final 8k block is also returned to the allocator. All pools sharing an allocator recycle memory that the allocator retains. The amount of memory the allocator retains can be influenced using apr_allocator_max_free_set(). In case you are wondering what I am babbling about allocators: APR creates an allocator at initialization, which is the allocator used by the internal root pool. A pool created with a NULL parent will be a child of the internal root pool and therefor inherit its allocator. HTH, Sander
RE: Pools, C++, and Exceptions Best Practices
On Thu, 2004-10-14 at 08:08, David Barrett wrote: -Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED] Subject: Re: Pools, C++, and Exceptions Best Practices You'll be eating through your available memory at a pretty quick rate this way. Each pool preallocates 8k. In your case this means that every object you instantiate, you allocate 8k. Does APR allocate 8k per root memory pool, or for subpool? Per pool, be it a root pool or a subpool. When I destroy a subpool does it recycle the memory? Yes. So, for example, how much memory (roughly) would the following code allocate: # apr_pool_t *root, *sub0, *sub1; # apr_pool_create( root, 0 ); # apr_pool_create( sub0, root ); # apr_pool_destroy( sub0 ); # apr_pool_create( sub1, root ); 16k. Basically, does a pool grow infinitely until it's destroyed, or does it recycle subpool memory? When a pool is cleared all of it's allocated memory except an 8k block is returned to the pools allocator. When a pool is destroyed, that final 8k block is also returned to the allocator. All pools sharing an allocator recycle memory that the allocator retains. The amount of memory the allocator retains can be influenced using apr_allocator_max_free_set(). In case you are wondering what I am babbling about allocators: APR creates an allocator at initialization, which is the allocator used by the internal root pool. A pool created with a NULL parent will be a child of the internal root pool and therefor inherit its allocator. HTH, Sander
APR 1.0.0 and CYGWIN
I was unable to build ARP-1.0.0 on CYGWIN. I get the following error: $ makemake[1]: Entering directory `/cygdrive/y/spryware/apr/apr-1.0.0'/bin/bash /cygdrive/y/spryware/apr/apr-1.0.0/libtool --silent --mode=compile gcc -g -O2 -DHAVE_CONFIG_H -DCYGWIN -I./include -I/cygdrive/y/spryware/apr/apr-1.0.0/include/arch/unix -I./include/arch/unix -I/cygdrive/y/spryware/apr/apr-1.0.0/include -o network_io/unix/sockopt.lo -c network_io/unix/sockopt.c touch network_io/unix/sockopt.lonetwork_io/unix/sockopt.c: In function `apr_socket_opt_set':network_io/unix/sockopt.c:135: error: `ttllevel' undeclared (first use in this function)network_io/unix/sockopt.c:135: error: (Each undeclared identifier is reported only oncenetwork_io/unix/sockopt.c:135: error: for each function it appears in.)network_io/unix/sockopt.c:136: error: `ttl' undeclared (first use in this function)make[1]: *** [network_io/unix/sockopt.lo] Error 1make[1]: Leaving directory `/cygdrive/y/spryware/apr/apr-1.0.0'make: *** [all-recursive] Error 1 Daniel May
Re: APR 1.0.0 and CYGWIN
Daniel, we really shouldn't be building unix/ on cygwin. In spite of the built-in support, it simply hasn't been vetted and is bound to have vulnerabilities if used for Apache 2.0. Ideally we should modify the configure.in for cygwin to determine win32/ as the build sources, and toggle -DWIN32. There are probably other side effects, but I'd be happy to help you work through them if you would like to help us put together a patch. In many cases (see the file lists in the .dsp win32 build files) we zig-zag between win32/ and unix/ in the same tree, and need to see how to do so effectively for cygwin. If we do this right, the same sources should build on both cygwin and mingw. Bill At 02:17 PM 10/14/2004, Daniel May wrote: I was unable to build ARP-1.0.0 on CYGWIN. I get the following error: $ make make[1]: Entering directory `/cygdrive/y/spryware/apr/apr-1.0.0' /bin/bash /cygdrive/y/spryware/apr/apr-1.0.0/libtool --silent --mode=compile gcc -g -O2 -DHAVE_CON FIG_H -DCYGWIN -I./include -I/cygdrive/y/spryware/apr/apr-1.0.0/include/arch/unix -I./include/arch /unix -I/cygdrive/y/spryware/apr/apr-1.0.0/include -o network_io/unix/sockopt.lo -c network_io/unix /sockopt.c touch network_io/unix/sockopt.lo network_io/unix/sockopt.c: In function `apr_socket_opt_set': network_io/unix/sockopt.c:135: error: `ttllevel' undeclared (first use in this function) network_io/unix/sockopt.c:135: error: (Each undeclared identifier is reported only once network_io/unix/sockopt.c:135: error: for each function it appears in.) network_io/unix/sockopt.c:136: error: `ttl' undeclared (first use in this function) make[1]: *** [network_io/unix/sockopt.lo] Error 1 make[1]: Leaving directory `/cygdrive/y/spryware/apr/apr-1.0.0' make: *** [all-recursive] Error 1 Daniel May
Re: Threads Best Practices
On Sun, 10 Oct 2004 09:12:53 +0200, Dror Shilo [EMAIL PROTECTED] wrote: Incidentally, will apr_os_thread_current( ) work on all platforms (specifically, Linux and Win32)? Am I understanding this correctly to mean that the function works on all platforms, but the return value is platform-specific? I cast it to integer , it is a unique number for the current process I'm sure all your z/OS users will be complaining since pthread_t is a structure there so apr_os_thread_current() won't return a scalar ;)
[announce] APR 1.0 Tutorial at ApacheCon
Sorry for the spam, but I just wanted to get the word out about the APR 1.0 Tutorial that Sander and I are doing at ApacheCon. We're hoping that some of you all who lurk on these lists and are interested in learning more about APR and the interface and features it provides might be able to convince your bosses to pay for you to come to the con and attend our tutorial. It's a three hour in-depth look at APR and how to use it. The full abstract is below. If you're interested, sign up asap -- if the number of people registered doesn't improve soon we might have to cancel the class altogether. Hope to see you there, Cliff T03: Apache Portable Runtime 1.0 Tutorial Day: Sat Time: 09h00 Session chair: None assigned Duration: 180 minutes Style: Tutorial Level: Experienced Audience: Developer Categories: Speaker: Cliff Woolley Speaker: Sander Striker As any systems programmer will know, one of the biggest headaches in writing a cross-platform application is dealing with the inconsistencies between various operating systems when trying to accomplish a given task. The Apache Portable Runtime is a portability library that seeks to bridge the gaps among these different platforms by providing a consistent interface for them all while attempting to provide maximum performance on each. It forms the underpinnings of both the Apache HTTP Server 2.0 and the Subversion revision control system, among other applications, freeing them from having to handle each new operating system as a special case. Though APR has been in development for several years, version 1.0 has finally hit the streets in its final form. This tutorial will give an overview of the features and APIs provided by APR 1.0 plus examples of how to use these features to make your own applications portable with ease. We will also demonstrate how APR's subsystems can be used together to build more complex applications by using them to construct a simple, portable web client that can fetch pages from a webserver and write them to disk.
Re: APR 1.0.0 and CYGWIN
William A. Rowe, Jr. wrote: Daniel, we really shouldn't be building unix/ on cygwin. In spite of the built-in support, it simply hasn't been vetted and is bound to have vulnerabilities if used for Apache 2.0. Ideally we should modify the configure.in for cygwin to determine win32/ as the build sources, and toggle -DWIN32. There are probably other side effects, but I'd be happy to help you work through them if you would like to help us put together a patch. In many cases (see the file lists in the .dsp win32 build files) we zig-zag between win32/ and unix/ in the same tree, and need to see how to do so effectively for cygwin. If we do this right, the same sources should build on both cygwin and mingw. Please please discuss this on the cygwin mailing lists before going down this course. Cygwin is supposed to be unix-like. Packages shouldn't need to start applying win32 specific tricks, and when they do, it often compromizes the unix-like feel that is a major feature of Cygwin. Max.
Re: APR 1.0.0 and CYGWIN
At 04:47 PM 10/14/2004, Max Bowsher wrote: Cygwin is supposed to be unix-like. Packages shouldn't need to start applying win32 specific tricks, and when they do, it often compromizes the unix-like feel that is a major feature of Cygwin. If cygwin used the unambiguous POSIX file flags and had close to 100% compatibility with a unix filesystem (no pathname ambiguity, case sensitive file names, valid filename characters of \ : etc) then there would be little concern for security, and it would be very rational to go with the unix flavor port.
Re: APR 1.0.0 and CYGWIN
I should have added that the pseudo-fork and condition vars on cygwin would actually be better preserved by using the unix port. In fact, if the cygwin build simply used the win32 apr_file_io code I'd be quite happy with it relying on the other (unambiguous) features of the cygwin API. Bill At 04:47 PM 10/14/2004, Max Bowsher wrote: Cygwin is supposed to be unix-like. Packages shouldn't need to start applying win32 specific tricks, and when they do, it often compromizes the unix-like feel that is a major feature of Cygwin. If cygwin used the unambiguous POSIX file flags and had close to 100% compatibility with a unix filesystem (no pathname ambiguity, case sensitive file names, valid filename characters of \ : etc) then there would be little concern for security, and it would be very rational to go with the unix flavor port.
