You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by je...@apache.org on 2004/06/04 11:38:50 UTC
cvs commit: apr STATUS
jerenkrantz 2004/06/04 02:38:50
Modified: . STATUS
Log:
My rationale as to why this isn't a showstopper.
Revision Changes Path
1.200 +18 -1 apr/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apr/STATUS,v
retrieving revision 1.199
retrieving revision 1.200
diff -u -u -r1.199 -r1.200
--- STATUS 24 May 2004 08:44:37 -0000 1.199
+++ STATUS 4 Jun 2004 09:38:50 -0000 1.200
@@ -35,6 +35,23 @@
example, sys V semaphores don't have a file to open, so the child process
can't reaquire the lock.
+ jerenkrantz says: This is not a showstopper and I believe the above
+ analysis is slightly confusing. The real problem here is that
+ apr_*_mutex_child_init assumes a shared memory space - that is, the
+ children processes have access to the parent apr_*_mutex_t pointer. The
+ children just call child_init on the original, inherited apr_*_mutex_t.
+ Unlike globalmutexchild in test, apr_*_mutex_create is *not* intended to
+ be called from the child and subsequently call child_init. Instead,
+ apr_create_proc is intended to exec separate processes with disjoint
+ memory addresses. Currently, APR does not provide a cross-platform
+ mechanism for joining an already existing lock. A simple
+ 'apr_*_mutex_join' which is intended to be called from separate
+ processes to an already-existing lock would solve this problem.
+ child_init is not intended to be used this way. Even with SysV
+ semaphores, using IPC_PRIVATE should still work due to the parent-child
+ relationship. A strawman has been posted to dev@apr:
+ Message-Id: <213031CF0406DE1AC426A411@[10.0.1.137]>
+
* Must namespace protect all include/apr_foo.h headers. Jon Travis
has especially observed these including apr within Apache-1.3.
Message-ID: <20...@covalent.net>