apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject documented 1.0 showstoppers
Date Thu, 03 Jun 2004 10:27:05 GMT
Who is going to do anything about these showstoppers and when?  If no action, I 
don't see why they should be considered showstoppers.

 From the STATUS file:

RELEASE 1.0 SHOWSTOPPERS:

* apr_global_mutex_child_init and apr_proc_mutex_child_init aren't
   portable.	 There are a variety of problems with the locking API when it
   is used with apr_create_proc instead of apr_fork.	 First, _child_init
   doesn't take a lockmech_e parameter so it causes a segfault after the
   apr_proc_create, because the proc_mutex field hasn't been initialized.
   When the lockmech_e parameter is added, it _still_ doesn't work, because
   some lock mechanisms expect to inherit from the parent process.  For
   example, sys V semaphores don't have a file to open, so the child process
   can't reaquire the lock.

Certainly an interesting issue...

* Must namespace protect all include/apr_foo.h headers.  Jon Travis
   has especially observed these including apr within Apache-1.3.
   Message-ID: <20020128100116.A4288@covalent.net>
   Deprecating the symbols in 0.9, eliminating them with 1.0.
   (Those problems have been fixed, but it is a good example of
   what to look for.)
   Some headers with issues:
	apr.hnw			(READDIR_IS_THREAD_SAFE, ENUM_BITFIELD,
                               _POSIX_THREAD_SAFE_FUNCTIONS (?))

Certainly a good thing to clean up.  I'll make a pass through our public header 
files by this coming Sunday evening to see what other unprotected symbols, if 
any, we expose, if a regular expression junkie doesn't beat me to it.

* Flush out the test suite and make sure it passes on all platforms.
   We currently have about 450 functions in APR and 147 tests.  That
   means we have a large number of functions that we can't verify are
   actually portable.  This TODO includes finishing the migration to the
   unified test suite, and adding more tests to make the suite
   comprehensive.

If somebody wants this done, they should do it quick.  Not a reason to hold up 
1.0 release IMO.  I'm curious to see how many people think it is a reason to 
hold up 1.0 AND are willing to make significant contributions to fulfilling the 
goal.

* Eliminate the TODO's and XXX's by using the doxygen @bug feature
   to allow us to better track the open issues, and provide historical
   bug lists that help porters understand what was wrong in the old
   versions of APR that they would be upgrading from.

If somebody wants this done, they should do it quick.  Not a reason to hold up 
1.0 release IMO.  I'm curious to see how many people think it is a reason to 
hold up 1.0 AND are willing to make significant contributions to fulfilling the 
goal.


Mime
View raw message