Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(213)

Unified Diff: fusl/src/stdio/__lockfile.c

Issue 1714623002: [fusl] clang-format fusl (Closed) Base URL: git@github.com:domokit/mojo.git@master
Patch Set: headers too Created 4 years, 10 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
Index: fusl/src/stdio/__lockfile.c
diff --git a/fusl/src/stdio/__lockfile.c b/fusl/src/stdio/__lockfile.c
index 9d967d6eb8860c0522b9fcd8505d6e52fad19b6b..0e572e6deab71b383731e09a39d9ab3dde860c18 100644
--- a/fusl/src/stdio/__lockfile.c
+++ b/fusl/src/stdio/__lockfile.c
@@ -1,28 +1,27 @@
#include "stdio_impl.h"
#include "pthread_impl.h"
-int __lockfile(FILE *f)
-{
- int owner, tid = __pthread_self()->tid;
- if (f->lock == tid)
- return 0;
- while ((owner = a_cas(&f->lock, 0, tid)))
- __wait(&f->lock, &f->waiters, owner, 1);
- return 1;
+int __lockfile(FILE* f) {
+ int owner, tid = __pthread_self()->tid;
+ if (f->lock == tid)
+ return 0;
+ while ((owner = a_cas(&f->lock, 0, tid)))
+ __wait(&f->lock, &f->waiters, owner, 1);
+ return 1;
}
-void __unlockfile(FILE *f)
-{
- a_store(&f->lock, 0);
+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. */
+ /* 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);
+ if (f->waiters)
+ __wake(&f->lock, 1, 1);
}

Powered by Google App Engine
This is Rietveld 408576698