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);
