Here are some things I've either been meaning to do or thing that I
just don't want to forget about.
-aaron
Index: srclib/apr/STATUS
===================================================================
RCS file: /home/cvspublic/apr/STATUS,v
retrieving revision 1.65
diff -u -r1.65 STATUS
--- srclib/apr/STATUS 2001/09/20 16:26:07 1.65
+++ srclib/apr/STATUS 2001/09/24 07:13:37
@@ -28,6 +28,13 @@
since apr_proc_create didn't allocate the apr_proc_t storage.
(Aren't transparent types swell?) Suggestions?
+ * The new lock API is a full replacement for the old API, save
+ for the apr_lock_data_get/apr_lock_data_set functions. These
+ should be translated into apr_proc_mutex_data_get and
+ apr_proc_mutex_data_set to be complete.
+ Status: This should be in place before we make an APR release.
+ Aaron will do it unless someone beats him to it.
+
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Get OTHER_CHILD support into Win32
@@ -212,6 +219,28 @@
FreeBSD.
MsgID: <[EMAIL PROTECTED]>
+
+ * Currently it is difficult if not impossible to return a proper
+ status code from a thread using apr_thread_exit(), since the
+ value must be a (apr_status_t*), but the pool where this would
+ normally be allocated is in that same function immediately
+ thereafter destroyed. Simply changing the type of this parameter
+ to (apr_status_t) should solve the problem (along with some
+ internal changes in apr_thread_join() to accomodate).
+ Status: Aaron is working on this.
+
+ * There are some optimizations that can be done to the new
+ apr_proc_*() functions (on UNIX). One that may reduce pointer
+ indirection would be to make the apr_proc_mutex_unix_lock_methods_t
+ first-class members of the apr_proc_mutex_t structure.
+
+ * Condition variables are tricky enough to use, and even trickier
+ to implement properly. We could really use a better test case
+ for those subtle quirks that sometimes creep into CV implementations.
+
+ * Once we are fully satisfied with the new lock API, we can
+ begin to migrate the old API to be implemented on top of the
+ new one, or just decide to get rid of it altogether.
Documentation that needs writing:
