From f1c1a5ea8295a3f8e9ea2db8961c5a68e1a3f9ed Mon Sep 17 00:00:00 2001 From: Rich Felker Date: Mon, 10 Dec 2012 18:31:39 -0500 Subject: document self-synchronized destruction issue for stdio locking --- src/stdio/__lockfile.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'src/stdio') diff --git a/src/stdio/__lockfile.c b/src/stdio/__lockfile.c index 3bf3c26b..9d967d6e 100644 --- a/src/stdio/__lockfile.c +++ b/src/stdio/__lockfile.c @@ -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); } -- cgit v1.2.1