Improve comment

Author: mhsmith

Android/testbed/app/src/main/python/main.py

@@ -5,18 +5,21 @@
 import sys
 
 # Some tests use SIGUSR1, but that's blocked by default in an Android app in
-# order to make it available to `sigwait` in the Signal Catcher thread. That
-# thread's functionality is only useful for debugging the JVM, so disabling it
-# should not weaken the tests.
+# order to make it available to `sigwait` in the Signal Catcher thread.
+# (https://cs.android.com/android/platform/superproject/+/android14-qpr3-release:art/runtime/signal_catcher.cc).
+# That thread's functionality is only useful for debugging the JVM, so disabling
+# it should not weaken the tests.
 #
-# Simply unblocking SIGUSR1 is enough to fix most tests that use it. But in
-# tests that generate multiple different signals in quick succession, it's
-# possible for SIGUSR1 to arrive while the main thread is busy running the
-# C-level handler for a different signal, in which case the SIGUSR1 may be sent
-# to the Signal Catcher thread instead. When this happens, there will be a log
+# There's no safe way of stopping the thread completely (#123982), but simply
+# unblocking SIGUSR1 is enough to fix most tests.
+#
+# However, in tests that generate multiple different signals in quick
+# succession, it's possible for SIGUSR1 to arrive while the main thread is busy
+# running the C-level handler for a different signal. In that case, the SIGUSR1
+# may be sent to the Signal Catcher thread instead, which will generate a log
 # message containing the text "reacting to signal".
 #
-# In such cases, the tests may need to be changed. Possible workarounds include:
+# Such tests may need to be changed in one of the following ways:
 #   * Use a signal other than SIGUSR1 (e.g. test_stress_delivery_simultaneous in
 #     test_signal.py).
 #   * Send the signal to a specific thread rather than the whole process (e.g.