document self-synchronized destruction issue for stdio locking
authorRich Felker <dalias@aerifal.cx>
Mon, 10 Dec 2012 23:31:39 +0000 (18:31 -0500)
committerRich Felker <dalias@aerifal.cx>
Mon, 10 Dec 2012 23:31:39 +0000 (18:31 -0500)
src/stdio/__lockfile.c

index 3bf3c26bb86ea2cb9cfef4701bf5cf9599fdaa5e..9d967d6eb8860c0522b9fcd8505d6e52fad19b6b 100644 (file)
@@ -14,5 +14,15 @@ int __lockfile(FILE *f)
 void __unlockfile(FILE *f)
 {
        a_store(&f->lock, 0);
+
+       /* The following read is technically invalid under situations
+        * of self-synchronized destruction. Another thread may have
+        * called fclose as soon as the above store has completed.
+        * Nonetheless, since FILE objects always live in memory
+        * obtained by malloc from the heap, it's safe to assume
+        * the dereferences below will not fault. In the worst case,
+        * a spurious syscall will be made. If the implementation of
+        * malloc changes, this assumption needs revisiting. */
+
        if (f->waiters) __wake(&f->lock, 1, 1);
 }