gh-71052: Use raise_signal rather than kill in ThreadSignals.test_signals

[mhsmith]

On Android, we run the test suite embedded in a standard app, in order to be representative of the environment where Python is most likely to be used. This means there's a native thread that uses sigwait to listen for SIGUSR1 in a loop, and responds by triggering the Java garbage collector and logging a message. This is only used for debugging purposes, and in most cases it doesn't matter because any signal handler will take priority over it.

However, in ThreadSignals.test_signals there's a background thread which sends both SIGUSR1 and SIGUSR2, and then immediately exits. So if the background thread is unavailable because it’s exited, and the main thread is unavailable because it’s already processing one of the signals (see complete_signal in kernel/signal.c), then the other signal may be delivered to Android’s sigwait loop instead of the test's own handler. This happens about 1 time out of 4.

This PR fixes that by sending the signals using raise_signal (which is directed at the current thread) rather than os.kill (which is directed at the whole process). Not only does this avoid the above scenario, it also strengthens the test by verifying that a signal which is delivered to a background thread, and not merely sent by it, still runs the Python-level handler on the main thread.

Since raise "shall not return until after the signal handler does", this also allows for the removal of a whole block of code which waits for the signal to arrive.

• Issue: Meta-issue: support of the android platform #71052

[mhsmith]

This is a minor change to a test, so no news entry is required.

[mhsmith]

@vstinner: There's no CODEOWNERS entry for signals, but you've done some work in this area recently. Are you able to review this PR?

[vstinner]

LGTM.

The change works as expected. I stressed the test with ./python -m test test_threadsignals -m test_signals -j250 -F . The system load was around 225.00 on a laptop with 12 logicial CPUs (6 cores), the test ran successfully 1676 times in 2 minutes.

[miss-islington-app]

Thanks @mhsmith for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @mhsmith for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

[bedevere-app]

GH-116617 is a backport of this pull request to the 3.11 branch.

[bedevere-app]

GH-116618 is a backport of this pull request to the 3.12 branch.

[vstinner]

Merged, thanks!

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot ARM64 macOS 3.x has failed when building commit 34920f3.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/725/builds/7335) and take a look at the build logs.
4. Check if the failure is related to this commit (34920f3) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/725/builds/7335

Failed tests:

• test.test_asyncio.test_server

Failed subtests:

• test_abort_clients - test.test_asyncio.test_server.TestServer2.test_abort_clients

Summary of the results of the build (if available):

==

Click to see traceback logs

Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/async_case.py", line 93, in _callTestMethod
    if self._callMaybeAsync(method) is not None:
       ~~~~~~~~~~~~~~~~~~~~^^^^^^^^
  File "/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/async_case.py", line 115, in _callMaybeAsync
    return self._asyncioRunner.run(
           ~~~~~~~~~~~~~~~~~~~~~~~^
        func(*args, **kwargs),
        ^^^^^^^^^^^^^^^^^^^^^^
        context=self._asyncioTestContext,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/asyncio/base_events.py", line 721, in run_until_complete
    return future.result()
           ~~~~~~~~~~~~~^^
  File "/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/test_asyncio/test_server.py", line 231, in test_abort_clients
    s_sock = s_wr.get_extra_info('socket')
             ^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get_extra_info'