Fix references to _emscripten_main_thread_futex in comments. NFC

Author: sbc100

system/lib/pthread/emscripten_futex_wait.c

@@ -18,18 +18,19 @@ extern void* _emscripten_main_thread_futex;
 int _emscripten_thread_supports_atomics_wait(void);
 
 static int futex_wait_busy(volatile void *addr, uint32_t val, double timeout) {
-  // Atomics.wait is not available in the main browser thread, so simulate it via busy spinning.
+  // Atomics.wait is not available in the main browser thread, so simulate it
+  // via busy spinning.
   double now = emscripten_get_now();
   double end = now + timeout;
 
-  // Register globally which address the main thread is simulating to be
-  // waiting on. When zero, the main thread is not waiting on anything, and on
-  // nonzero, the contents of the address pointed by _emscripten_main_thread_futex
-  // tell which address the main thread is simulating its wait on.
-  // We need to be careful of recursion here: If we wait on a futex, and
-  // then call _emscripten_yield() below, that will call code that takes the
-  // proxying mutex - which can once more reach this code in a nested call. To
-  // avoid interference between the two (there is just a single
+  // Register globally which address the main thread is simulating to be waiting
+  // on. When zero, the main thread is not waiting on anything, and on nonzero,
+  // the contents of the address pointed by _emscripten_main_thread_futex tell
+  // which address the main thread is simulating its wait on.  We need to be
+  // careful of recursion here: If we wait on a futex, and then call
+  // _emscripten_yield() below, that will call code that takes the proxying
+  // mutex - which can once more reach this code in a nested call. To avoid
+  // interference between the two (there is just a single
   // _emscripten_main_thread_futex at a time), unmark ourselves before calling
   // the potentially-recursive call. See below for how we handle the case of our
   // futex being notified during the time in between when we are not set as the
@@ -68,16 +69,16 @@ static int futex_wait_busy(volatile void *addr, uint32_t val, double timeout) {
     //
     //  * wait on futex A
     //  * recurse into _emscripten_yield(),
-    //    which waits on futex B. that sets the _emscripten_main_thread_futex address to
-    //    futex B, and there is no longer any mention of futex A.
-    //  * a worker is done with futex A. it checks _emscripten_main_thread_futex but does
-    //    not see A, so it does nothing special for the main thread.
+    //    which waits on futex B. that sets the _emscripten_main_thread_futex
+    //    address to futex B, and there is no longer any mention of futex A.
+    //  * a worker is done with futex A. it checks _emscripten_main_thread_futex
+    //    but does not see A, so it does nothing special for the main thread.
     //  * a worker is done with futex B. it flips mainThreadMutex from B
     //    to 0, ending the wait on futex B.
-    //  * we return to the wait on futex A. _emscripten_main_thread_futex is 0, but that
-    //    is because of futex B being done - we can't tell from
-    //    _emscripten_main_thread_futex whether A is done or not. therefore, check the
-    //    memory value of the futex.
+    //  * we return to the wait on futex A. _emscripten_main_thread_futex is 0,
+    //    but that is because of futex B being done - we can't tell from
+    //    _emscripten_main_thread_futex whether A is done or not. therefore,
+    //    check the memory value of the futex.
     //
     // That case motivates the design here. Given that, checking the memory
     // address is also necessary for other reasons: we unset and re-set our