Repository navigation
feat(libkernel): implement pthread_set_name_np - #3031
Conversation
pthread_set_name_np renames through scePthreadRename; a null name clears it, as in FreeBSD. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Linux check, since the runs above are Windows: ce98a61 merged onto
|
Dextroid17
left a comment
Dextroid17
left a comment
There was a problem hiding this comment.
This is the ideal shape for a resubmission: the same function as #1872, which was closed precisely because no title reached it — and now six do, with a table that shows it.
The evidence is what this tree asks for, and then a little more. A named title list, the exact FAIL: unresolved ELF import … from libkernel.prx line, each release ZIP checked against its catalog checksum, relinked, and run for twenty seconds — that answers the acceptance bar for six titles at once, and "still running at 20 s" is exactly the right measurement for a start-up import. The Quake II row saying the exit is most likely missing game data, and that it was not checked, is the honesty that makes the rest of the table worth trusting.
The implementation is the shape it should be. Renaming through the existing scePthreadRename reuses the code that already does this, clearing the name on a null pointer matches FreeBSD, and returning void so a failure is ignored is FreeBSD's behaviour too — which is what a name setter wants, since there is nothing a caller could usefully do with the error. (scePthreadRename returns EINVAL for a null thread rather than throwing, so the discard is clean.) Of the test's three calls, the read-back and the clear are asserted; the null-thread call is exercised without an assertion, enough to show it does not crash but not what it returns.
One question about limits, and the numbers are worth stating exactly. Linux truncates a thread name to 16 bytes silently; FreeBSD's thr_set_name truncates to MAXCOMLEN + 1, which is 20. In this tree the write is unbounded while the read-back is cut to THREAD_NAME_CAPACITY - 1, 31 bytes — so a name longer than the console allows is stored in full and read back shortened, rather than refused. Is the console's own limit known, or is that a line for the entry? It is the one place a very long name behaves differently.
Written with AI assistance.
|
More titles that stop at
These add to @babyhuey's table above. AI-assisted: yes (the write-up; the rig run and its log lines are real). |
What
pthread_set_name_np(oxMp8uPqa+U) isn't exported, and six catalog homebrew titles stop on it at start-up onmain:It renames through the existing
scePthreadRename. A null name clears the name, as in FreeBSD. Like FreeBSD's version it returns nothing, so a failure (for example a null thread) is ignored.Test (
guest_thread_self): the main thread's name reads back throughscePthreadGetnameafter a rename, is empty after a null name, and a null thread does nothing.This is #1872 again, which was closed while no title reached it on
mainyet. It's now the next stop for these titles.Tested
Title stops. Each release ZIP was checked against its catalog sha256, relinked with
relinker --windows --registry, and run for 20 s.mainb8a083boxMp8uPqa+U(pthread_set_name_np)oxMp8uPqa+UoxMp8uPqa+Un1KOc0lTUEs(arc4random_buf, #2865)oxMp8uPqa+UJb2uGFMr688(pthread_getaffinity_np)oxMp8uPqa+U-nvxBWa0iDs(gethostname, #2968)oxMp8uPqa+U-nvxBWa0iDs(gethostname, #2968)Tests:
pthread|thread|kerneltests: 25 of 25 pass.tools/check_conventions.pypasses.Setup: Windows 11 Pro (26200), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release. Not tested on Linux or macOS. @babyhuey checked the same change on Linux in #1872.
Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt.mdfiles or images added to the repository (attach them to this PR)🤖 Generated with Claude Code