|
5 | 5 | import sys
|
6 | 6 |
|
7 | 7 | # Some tests use SIGUSR1, but that's blocked by default in an Android app in
|
8 |
| -# order to make it available to `sigwait` in the "Signal Catcher" thread. That |
9 |
| -# thread's functionality is only relevant to the JVM ("forcing GC (no HPROF) and |
10 |
| -# profile save"), so disabling it should not weaken the tests. |
| 8 | +# order to make it available to `sigwait` in the Signal Catcher thread. |
| 9 | +# (https://cs.android.com/android/platform/superproject/+/android14-qpr3-release:art/runtime/signal_catcher.cc). |
| 10 | +# That thread's functionality is only useful for debugging the JVM, so disabling |
| 11 | +# it should not weaken the tests. |
| 12 | +# |
| 13 | +# There's no safe way of stopping the thread completely (#123982), but simply |
| 14 | +# unblocking SIGUSR1 is enough to fix most tests. |
| 15 | +# |
| 16 | +# However, in tests that generate multiple different signals in quick |
| 17 | +# succession, it's possible for SIGUSR1 to arrive while the main thread is busy |
| 18 | +# running the C-level handler for a different signal. In that case, the SIGUSR1 |
| 19 | +# may be sent to the Signal Catcher thread instead, which will generate a log |
| 20 | +# message containing the text "reacting to signal". |
| 21 | +# |
| 22 | +# Such tests may need to be changed in one of the following ways: |
| 23 | +# * Use a signal other than SIGUSR1 (e.g. test_stress_delivery_simultaneous in |
| 24 | +# test_signal.py). |
| 25 | +# * Send the signal to a specific thread rather than the whole process (e.g. |
| 26 | +# test_signals in test_threadsignals.py. |
11 | 27 | signal.pthread_sigmask(signal.SIG_UNBLOCK, [signal.SIGUSR1])
|
12 | 28 |
|
13 | 29 | sys.argv[1:] = shlex.split(os.environ["PYTHON_ARGS"])
|
|
0 commit comments