apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j..@apache.org
Subject cvs commit: apr/locks/unix crossproc.c proc_mutex.c
Date Fri, 05 Apr 2002 13:49:45 GMT
jim         02/04/05 05:49:45

  Modified:    locks/unix crossproc.c proc_mutex.c
  Log:
  Be a bit more clear about the FIXME statement and the exact
  window we're concerned about.
  
  When oh when will we depreciate the old locking stuff :)
  
  Revision  Changes    Path
  1.60      +7 -3      apr/locks/unix/crossproc.c
  
  Index: crossproc.c
  ===================================================================
  RCS file: /home/cvs/apr/locks/unix/crossproc.c,v
  retrieving revision 1.59
  retrieving revision 1.60
  diff -u -r1.59 -r1.60
  --- crossproc.c	4 Apr 2002 18:33:56 -0000	1.59
  +++ crossproc.c	5 Apr 2002 13:49:45 -0000	1.60
  @@ -98,9 +98,13 @@
        *
        * Because of this, we ignore fname and craft our own.
        *
  -     * FIXME: if we try to create another semaphore within a second
  -     * of creating this on, we won't get a new one but another
  -     * reference to this one.
  +     * FIXME: There is a small window of opportunity where
  +     * instead of getting a new semaphore descriptor, we get
  +     * a previously obtained one. This can happen if the requests
  +     * are made at the "same time" (within a second, due to the
  +     * apr_time_now() call) and in the small span of time between
  +     * the sem_open and the sem_unlink. Use of O_EXCL does not
  +     * help here however...
        */
       epoch = apr_time_now() / APR_USEC_PER_SEC;
       apr_snprintf(semname, sizeof(semname), "/ApR.%lx", epoch);
  
  
  
  1.15      +7 -3      apr/locks/unix/proc_mutex.c
  
  Index: proc_mutex.c
  ===================================================================
  RCS file: /home/cvs/apr/locks/unix/proc_mutex.c,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- proc_mutex.c	4 Apr 2002 18:33:56 -0000	1.14
  +++ proc_mutex.c	5 Apr 2002 13:49:45 -0000	1.15
  @@ -99,9 +99,13 @@
        *
        * Because of this, we ignore fname and craft our own.
        *
  -     * FIXME: if we try to create another semaphore within a second
  -     * of creating this on, we won't get a new one but another
  -     * reference to this one.
  +     * FIXME: There is a small window of opportunity where
  +     * instead of getting a new semaphore descriptor, we get
  +     * a previously obtained one. This can happen if the requests
  +     * are made at the "same time" (within a second, due to the
  +     * apr_time_now() call) and in the small span of time between
  +     * the sem_open and the sem_unlink. Use of O_EXCL does not
  +     * help here however...
        */
       epoch = apr_time_now() / APR_USEC_PER_SEC;
       apr_snprintf(semname, sizeof(semname), "/ApR.%lx", epoch);
  
  
  

Mime
View raw message