apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject cvs commit: apr STATUS
Date Fri, 04 Jun 2004 09:38:50 GMT
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: <20020128100116.A4288@covalent.net>
  
  
  

Mime
View raw message