[Wakiki93]

What

An ITIMER_REAL or alarm expiry with SIGALRM blocked threw ITIMER_REAL (...) expired while SIGALRM is blocked: pending signals are not implemented. Since upstream added a process-wide pending set (28063f1, "wait for pending guest signals in the signal waits"), blocked signals can stay pending, so the expiry now marks SIGALRM pending exactly as a blocked raise does, instead of throwing.

This follows FreeBSD 11's realitexpire (kern_time.c), which sends SIGALRM through kern_psignal and tdsendsignal, where a masked signal is held. With it, sigwait, sigwaitinfo and sigtimedwait take the expiry, and unblocking it runs a registered handler. Expiries with SIG_IGN, and unblocked expiries (default disposition exits with 142, a handler throws), are unchanged.

This is the pattern QEMU's qemu_signal_init uses: it blocks SIGIO, SIGALRM and SIGBUS and takes them with sigwait on a dedicated thread (compatfd.c), so an armed QEMU timer would otherwise end the process at its first expiry. The setitimer entry in docs/dev/debt/libkernel.md is updated: the pending siginfo_t reports SI_USER like the other pending signals (the kernel reports SI_KERNEL), and one pending instance absorbs further expiries until it is taken.

Tested

Linux, Ubuntu 24.04 x86_64, GCC 13.3, -DBUILD_TESTING=ON. Two cases added to guest_sigtimedwait: SIGALRM blocked, a 50 ms one-shot setitimer, sigtimedwait returns 14; and with a handler registered, the expiry stays pending while blocked and the handler runs when _sigprocmask unblocks it. On unpatched main the test aborts with the pending signals are not implemented error; with the change it passes. guest_sigtimedwait, guest_signals, guest_itimer, guest_getitimer, guest_signal_sets and guest_user_context pass; guest_sigtimedwait passed 10 sequential runs and 3 parallel runs under CPU oversubscription (0.6 s each). tools/check_conventions.py passes. Not tested on Windows or macOS, or on a title.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes

🤖 Generated with Claude Code

https://claude.ai/code/session_017b3iPcA6fL66awNGDnP8wo

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
#5112	docs/dev/debt/libkernel.md L105-106

[Wakiki93]

Not a dependency: #4938 and #5112 change file I/O and edit the "Windows file identity" entry in docs/dev/debt/libkernel.md, while this PR edits the adjacent setitimer entry. The only overlap is that adjacent-line text conflict. I'll rebase whichever merges second.

[oneandonlydean]

Closing: no title is known to reach this. With the queue at 700+ open PRs, please hold off on new PRs that don't name a title needing the change until it's down. If a title stops on this on current main, reopen with the title ID and the log line.