[milescoviello]

What

scePthreadCondattrSetclock and scePthreadCondattrDestroy threw std::invalid_argument for a null or uninitialized attribute. FreeBSD 11's libthr _pthread_condattr_setclock and _pthread_condattr_destroy return EINVAL for one, as the other scePthread attribute calls here already do (scePthreadAttrDestroy, scePthreadAttrSetdetachstate, ...). Both now return SCE_KERNEL_ERROR_EINVAL (0x80020016), which pthread_condattr_setclock maps to EINVAL.

The clock id is still stored as given. libthr accepts only CLOCK_REALTIME, CLOCK_VIRTUAL, CLOCK_PROF and CLOCK_MONOTONIC. But there's no console evidence for which ids PS5's scePthreadCondattrSetclock takes, and pthread_cond_timedwait here serves the other ids clock_gettime supports, so this PR leaves them working (see the review below).

I don't know of a title that hits this. I found it while comparing the condition-variable attribute calls with libthr.

Tested

Ubuntu 24.04, GCC 13.3, Release, on main 6a32550.

• guest_pthread_condattr (new): a null or unset attribute gives 0x80020016 from both calls and EINVAL from pthread_condattr_setclock. Clocks 0, 1, 2, 4, 5 and 12 are accepted by both setclock calls. Destroying twice gives 0x80020016 the second time. With main's Cond.cpp the test aborts on the first call (the throw). With this change it passes 3 of 3.
• ctest -R '^guest_|libc': 403 of 403 pass, with this and one other small libkernel fix applied together.
• tools/check_conventions.py passes. tools/pr_overlap.py finds no conflicting lines. It couldn't compare against Macos m4 #6222, fix(libc): append stream writes atomically on Windows #6287, fix(libkernel): refuse to detach or rejoin a thread that is being joined #6487 and fix(libkernel): reject port-zero connect on unconnected sockets #6884, which conflict with main and touch CMakeLists.txt. The new test is registered away from the one fix(libkernel): keep a finished Windows thread's stack until it is joined or detached #4563 adds, and git merge-tree merges this branch with fix(libkernel): keep a finished Windows thread's stack until it is joined or detached #4563 and fix(libkernel): report thread guard size from attribute queries #6893 cleanly.
• Windows 11 Pro, Ryzen 7 5700X, WinLibs GCC 15.2.0 r7, Release, with the ten PRs of this series merged in order: this PR's test passes 3 of 3, and with only this PR's source reverted it fails with main's behaviour. (series run by @screamm)

Not checked: macOS, a console.

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 under Silent stubs in their library's technical debt file
• 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
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

🤖 Generated with Claude Code

[oneandonlydean]

@milescoviello thanks, the review passed and this matches FreeBSD 11 libthr (thr_condattr.c accepts only REALTIME/VIRTUAL/PROF/MONOTONIC).

One question before we merge. On main, setclock stores any id, and timedwait then uses it through clock_gettime, which also serves 5, 7, 11, 12, 14 and 15 (UPTIME, the _PRECISE/_FAST variants and the CPU clocks). With this PR those clocks now return EINVAL. A title that ignores the error would keep REALTIME while it computes deadlines on its uptime clock, so its timedwait would time out immediately.

Do you have console evidence (a hardware trace or a homebrew test) that PS5's scePthreadCondattrSetclock rejects those clocks too? If Sony's libthr accepts any of them, we'd want to keep those working.

[github-actions]

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 4972	core/libs/prx/libkernel/CMakeLists.txt
PR 5021	core/libs/prx/libkernel/CMakeLists.txt
PR 6044	core/libs/prx/libkernel/CMakeLists.txt
PR 6222	core/libs/prx/libkernel/CMakeLists.txt
PR 6287	core/libs/prx/libkernel/CMakeLists.txt
PR 6487	core/libs/prx/libkernel/CMakeLists.txt

[milescoviello]

Thanks for checking. No, I don't have console evidence. The PR only cited FreeBSD 11's libthr, and I'd marked the PS5 side as unchecked. You're right that rejecting 5, 7, 11–15 could break a title that uses one of them and ignores the error, where it works today.

I've dropped the clock check (62ac8d6, force-pushed as one commit). scePthreadCondattrSetclock stores any id again, as on main. What's left is EINVAL from scePthreadCondattrSetclock and scePthreadCondattrDestroy for a null or uninitialized attribute, where main throws. The test now also checks that 5 and 12 are accepted. I updated the title and description to match.

AI-assisted: yes (Claude Code)

[screamm]

Windows run in #7023 (comment) on the trimmed head 62ac8d6: guest_pthread_condattr 3/3, and clocks 0, 1, 2, 4, 5 and 12 are accepted, so the clock ids oneandonlydean asked about keep working. With the source reverted: "Condition attributes are not initialized".

Written with Claude Code assistance (validation by a subagent, reviewed in this session).