[Lorkydey]

What

Fix the Windows socket stop poll: POLLPRI is not supported by WSAPoll. Ask WSAPoll for POLLRDBAND when the guest requests POLLPRI, and for POLLRDNORM when it requests POLLIN, keeping urgent data separate from ordinary readability. Returned flags are still masked by the guest's requested events. Linux keeps its native mapping.

Carries screamm's 1a20b493 implementation and urgent-data tests with the original author preserved. Rebased onto main 2a2a3dc650b9245fb0fb9b088afb1a6c27637f7d at head 5db1d8d5e933c5096ed87530898c2989becec4d7, after #4391 merged. The resolution retains main's allocated socket descriptors, its descriptor lookup, the pipe-poll tests from #3644, all urgent-data tests and both sets of limitations in docs/dev/debt/libkernel.md. The Windows event mapping itself is unchanged.

The mapping follows WSAPoll's documented flags and FreeBSD 11.4's sopoll_generic. Winsock keeps reporting urgent data until it is read with MSG_OOB, whereas FreeBSD stops once the normal stream passes the urgent mark. The existing debt entry retains that difference and the guest's unsupported MSG_OOB send/receive behavior. This removes a runtime refusal; it adds no newly implemented export to the progress scanner.

Title evidence

• Original PSXS5 (PPSA97510), SwanStation (PPSA98510) and ProsperoTV (PPSA99003, bring-up Four open-source homebrew titles stop at start-up on unresolved imports (sysctl, pthread_set_name_np, isatty, mkstemp, signal sets, Opus decoders) #1578) traces are in libkernel: poll throws for POLLPRI on guest sockets under WSAPoll (PSXS5, SwanStation, ProsperoTV after #3649); fix branch ready, PSXS5 renders #4478.
• babyhuey's Windows retest after #3644 merged used main d1fd9372 and a local integration 0343f291: Nuvio Max'd (PPSA99288) and ProsperoAI (PPSA99004) both pass this stop and render for 60 seconds; ProsperoTV passes it and reaches a separate fcntl record-lock refusal. Those runs used main's test file, without the urgent-data regressions; the validation below now retains and runs both sets of tests.
• These are the other contributors' title runs, not new title runs on the rebased head. No personal title retest or FPS improvement is claimed here.

Tested

• Windows 11 Pro 26100, WinLibs MinGW-w64 GCC 15.2.0 r7, Ninja, Release, BUILD_TESTING=ON: full runtime (libs), relinker and the four focused targets build at exact head 5db1d8d5e. Local ANYPS5_ENABLE_SPIRV_TOOLS=OFF.
• guest_poll, guest_socket_pair, guest_udp and guest_sce_net each pass five consecutive runs, retaining pipe, descriptor and urgent-data coverage.
• Windows negative control: the combined test with only Udp.cpp replaced by main 2a2a3dc65 fails at poll: POLLPRI is not supported by WSAPoll. Restoring the PR source and rebuilding passes all four tests five times again.
• Public validation of this exact revision: Linux and Windows full runtime/relinker builds and all four tests repeated five times pass. The Windows job also verifies the main negative control before restoring/retesting the source. Conventions and whitespace pass on both hosts; test registration passes on Linux. The workflow lives on a separate CI branch and explicitly checks out the PR source.
• Local conventions, test registration and git diff --check pass. These are focused checks, not the full CTest suite. Full upstream jobs require a maintainer dispatch. No new title run on this rebased revision is claimed.

Merge order

#3644 and #4391 are now merged and are included through the main baseline. The earlier proposed ordering with #4391 is therefore superseded. This rebase retains its descriptor allocation/read/write behavior and validates the combined socket tests. #3649 and #4351 remain closed; no socket-fstat implementation from #4351 is carried here.

Remaining open-PR overlaps

After this rebase, pairwise merges against #4903 2cd842efa (socket fstat) and #4933 bc299f299 (polling libSceNet sockets) conflict only in docs/dev/debt/libkernel.md. Their source changes merge textually with this head; this is not a combined runtime validation.

Proposed order: #4525 first, then those branches rebase; that order is not yet agreed with their authors. For #4903, retain its socket-stat limitations and this PR's urgent-data limitations. For #4933, retain its libSceNet socket lookup/ownership and mixed-descriptor support, while removing the obsolete Windows POLLPRI refusal and keeping POLLPRI -> POLLRDBAND, POLLIN -> POLLRDNORM, requested-event masking, pipe tests and urgent-data tests. If either lands first, this PR will need the small debt resolution and focused socket tests again. Neither is a runtime prerequisite for this standalone fix.

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; no silent stub added
• No notes, investigation .md files or images added to the repository
• New third-party code is a submodule built from source (none added)
• Generic behaviour, not specific to one title
• Depends on: none
• Unblocks: PPSA97510, PPSA98510, PPSA99003 Four open-source homebrew titles stop at start-up on unresolved imports (sysctl, pthread_set_name_np, isatty, mkstemp, signal sets, Opus decoders) #1578 (title evidence in libkernel: poll throws for POLLPRI on guest sockets under WSAPoll (PSXS5, SwanStation, ProsperoTV after #3649); fix branch ready, PSXS5 renders #4478 and the linked retest above)
• AI-assisted: yes (screamm's Claude Code implementation; Codex integration and validation)

[Dextroid17]

On Linux this path is not compiled, so a green here cannot stand for the Windows behaviour — and the report side cannot drift from this change. The change sits inside #ifdef _WIN32: guest_poll passes at the head (100% of 1, exit 0) and passes identically with the parent's Udp.cpp in place, which is the expected no-op rather than evidence either way.

What I could check without a Windows host:

• revents is filled by walking the same table the request side uses — core/libs/prx/libkernel/Socket/src/Udp.cpp:987-989 at 35893ea90:

for (const auto& flag : RequestFlags)
    if ((entry.events & flag.guest) && (native[i].revents & flag.native))
        entry.revents = static_cast<short>(entry.revents | flag.guest);

so re-pointing guest 0x1/0x2 at POLLRDNORM/POLLRDBAND changes what is reported as well, with no second table to keep in step.

• The Windows constants the mapping rests on, from mingw-w64's winsock2.h: POLLRDNORM 0x0100, POLLRDBAND 0x0200, POLLIN (POLLRDNORM | POLLRDBAND), POLLPRI 0x0400. POLLIN is a union there, so narrowing it to POLLRDNORM is what preserves the guest's distinction; POLLPRI is a distinct flag rather than an alias of POLLRDBAND, so sending the priority request to the priority-data flag is a mapping rather than a redefinition.
• The refusal this PR removes is the only one on this request path. The file's remaining throws are the unrelated socketpair and sendmsg refusals, plus the equeue WSAPoll failure at Udp.cpp:244 — a different call.

Informational, body only: the windows job in .github/workflows/build.yml is gated to push/workflow_dispatch (a maintainer can dispatch it for a PR number), so an ordinary PR run does not compile this branch, the Windows-only half of the new test included.

Written with AI assistance.

Hermes Agent 🤖 at your service

[xXPBSXx]

Windows test: head 35893ea90 merged onto current main d592d54e1 (clean merge, no conflicts). Windows 10, MinGW GCC (WinLibs), Ninja Release, -j2: full build 0 errors; ctest with the filter guest_poll: guest_poll passed (1 test(s), 0 failed); python tools/check_conventions.py --base upstream/main passed. I did not run the new tests against main without the change.

AI-assisted (Claude Code).

[Dextroid17]

This is the half I could not supply, and it is the same head I read (35893ea90). On this host the change is inside #ifdef _WIN32, so my run was a no-op — which is why I said a green here cannot stand for the Windows behaviour. Your run is that evidence, and it is now on the record.

One line is still missing on that side: the red arm. guest_poll passes at the head and passes identically with the parent's Udp.cpp in place, so on Windows too the green alone cannot separate the new mapping from a no-op. Running your filter against the parent's Udp.cpp with this test kept would, and it is cheap while the Windows tree is up.

Written with AI assistance.

[Lorkydey]

@DariusHQ @pushkarreddyy @milescoviello

Coordinating the overlap with #3644: #4525 carries the Windows socket POLLPRI mapping and urgent-data tests. The overlap flagged here is in GuestPoll.cpp and the shared poll debt entry; the pipe-readiness behavior belongs to the pipe-poll PR.

I propose landing the selected pipe-poll fix and #4351 before #4525. As Marc noted on #3649, #3644 and #3649 still need a maintainer choice, and #3649 also needs coordination with #4391. My current Depends on lists #3649 and #4351; I can update the pipe dependency if #3644 is selected instead.

After the agreed prerequisites land, I will rebase #4525, keep both the pipe and urgent-data tests (including their imports, declarations and calls), combine the debt descriptions, and preserve the Windows POLLIN -> POLLRDNORM / POLLPRI -> POLLRDBAND mapping. I will rerun the focused Windows/Linux tests after integration. This comment does not claim a combined validation with the current pipe-poll heads.

For this PR alone, the requested Windows negative control is now recorded in CI: replacing Udp.cpp with the parent makes the new test fail at the old POLLPRI refusal; restoring the patch makes all four focused tests pass three times.

Does that ordering work for you, subject to the maintainer's pipe-poll choice?

AI-assisted: yes (Codex).

[Dextroid17]

Thanks for pointing at the Windows negative control. One thing to line up before it counts for this head:

• The linked run (Lorkydey/AnyPS5 run 38302727370) reports head ede071e5784089def9b23f9c721d598ee7a4c64b.
• This PR's head is now 32b2eda2ca (single commit, "fix(libkernel): accept POLLPRI on guest sockets under WSAPoll"), updated 2026-10-12T22:17:56Z.

Could you confirm that the parent Udp.cpp swap (guest_poll fails at the old POLLPRI refusal, passes with the patch) was run on 32b2eda2ca? If the commit changed after that run, the red arm needs a re-run on the current head. I have no Windows host here, so I cannot reproduce it myself.

AI-assisted: yes (Claude Code).

[Lorkydey]

@Dextroid17 Yes, the Windows negative control was run on the current PR head, 32b2eda2ca394a43d46d60f09ea08a469ba7bd4c.

ede071e578 is the commit containing the separate validation workflow. The Windows job explicitly checks out the PR commit at line 18, and its checkout log confirms 32b2eda2ca394a43d46d60f09ea08a469ba7bd4c.

In that checkout, the negative-control step replaces only Udp.cpp with HEAD^ while retaining the new test. In the Windows job, guest_poll fails at poll: POLLPRI is not supported by WSAPoll; after restoring and rebuilding the PR source, all four focused tests pass three times.

The PR head still matches that tested commit. Thanks for checking the provenance!

AI-assisted: yes (Codex).

[Dextroid17]

@Lorkydey Thanks, you're right, and I checked the run log rather than taking the link on trust.

• The checkout step in run 38302727370 (job 114989316200) reads HEAD is now at 32b2eda fix(libkernel): accept POLLPRI on guest sockets under WSAPoll, which is the current PR head.
• The red arm is in the same job. With the parent Udp.cpp and the new test kept, guest_poll exits 0xc0000409 with poll: POLLPRI is not supported by WSAPoll. After the patch is restored, ctest -R "^(guest_poll|guest_socket_pair|guest_udp|guest_sce_net)$" --repeat until-fail:3 runs, so the green arm is recorded too.

That closes the provenance question, and the negative control is now on the record for this head. I still have no Windows host, so this is evidence from your CI log, not a run of mine.

AI-assisted: yes (Claude Code).

[babyhuey]

Title check on Windows 11 (WinLibs GCC 15.2, RTX 3080) now that #3644 is merged. On main d1fd937, three titles that used to stop at poll: descriptor N is not a socket stop at poll: POLLPRI is not supported by WSAPoll instead. This PR conflicts with main now, so I merged it locally (fork test/verify-pollpri, 0343f29). Udp.cpp merges clean; I kept main's GuestPoll.cpp for the merge and unioned the debt line, so this PR's new tests weren't part of these runs.

With it the POLLPRI throw is gone in all three:

• Nuvio Max'd (PPSA99288, --trap-sdk-syscall-stubs): renders for the full 60 s, [SX] 59.9 fps, worst frame 20.0-21.3 ms, no throw. This is the first time it renders on Windows.
• ProsperoAI (PPSA99004, --trap-sdk-syscall-stubs): renders and sits in its UI for 60 s, about 500 submissions per 10 s window, no throw. Its update check fails quietly.
• ProsperoTV (PPSA99003): gets into its HUI (swapchain, fonts, [HUI] pad open), then stops at a separate Windows-only throw, fcntl: record locks are not implemented on Windows, command=12, fd=4 (F_SETLK on a file).

The RequestFlags change maps guest POLLIN to POLLRDNORM and POLLPRI to POLLRDBAND on Windows. Results are still masked by entry.events, so the shared POLLRDNORM bit doesn't report anything the guest didn't ask for.

[Lorkydey]

@MarcZX100 A coordination note for #4391: #4525 is now rebased onto main c13dc7e6b at bf51a206c, retaining both the merged #3644 pipe tests and screamm's urgent-data tests. The Windows POLLIN -> POLLRDNORM and POLLPRI -> POLLRDBAND mapping remains independent of the socket descriptor allocation scheme.

Would #4525 before #4391 work for your next rebase? The combined GuestPoll.cpp should retain both groups of tests and the native socket includes/linkage, and the debt entry needs both the allocation/pipe semantics and the urgent-mark limitation. #4391 already conflicts with main, so I am not treating a pairwise merge conflict as a runtime dependency or claiming a combined build. The standalone rebased #4525 passes the four focused Windows tests three times, including the main-with-new-tests negative control.

AI-assisted: yes (Codex).

[Lorkydey]

@babyhuey Thanks for the title retests! Rebased onto main c13dc7e6b at bf51a206c, retaining both #3644's pipe tests and this PR's urgent-data tests, plus both debt descriptions. #3649 and #4351 are closed, so I removed those obsolete dependencies; no socket-fstat code from #4351 is included.

@Dextroid17 The negative control has also been rerun for this new head. Windows and Linux build libs, relinker and the focused targets; guest_poll, guest_socket_pair, guest_udp and guest_sce_net each pass three times. On Windows, replacing only Udp.cpp with parent main while keeping the combined test fails at the old POLLPRI refusal; restoring it makes the tests pass again. Linux is the non-regression check.

Both jobs explicitly check out bf51a206c6c80c0646605fbcfd44a588c46c9f3d; the separate workflow commit is 6ad548f0a. The description now links your title evidence separately from these focused tests. I have not rerun the titles on this rebased head or run the full CTest suite.

AI-assisted: yes (Codex).

[Dextroid17]

Thanks for rerunning. I confirmed the PR head is bf51a206c, the commit you named. Run 38341096951's head is the workflow commit 6ad548f0a, so I'm treating its Windows and Linux passes as your CI evidence, not a run of mine. I have no Windows host, so I can't verify the Windows result myself.

[babyhuey]

Native Windows check of the exact head bf51a20 (Windows 11, RTX 3080, WinLibs GCC 15.2, Release), as there was no Windows host on the earlier review:

• guest_poll, guest_socket_pair, guest_udp and guest_sce_net each pass 5/5 (--repeat until-fail:5). No warnings in Udp.cpp or GuestPoll.cpp.
• Udp.cpp is unchanged from the head I ran yesterday; what's new is the extra tests in GuestPoll.cpp and ws2_32 for guest_poll_tests.

The same three titles on this head alone (#4480 is merged now, so ProsperoTV needs nothing else), each running the full 60 s with no throw:

• ProsperoTV (PPSA99003): renders its menu, [TV] frames=600 mean=23.36ms ... draws=2 shapes=407.
• ProsperoAI (PPSA99004, --trap-sdk-syscall-stubs): renders and sits in its UI, about 590 submissions per 10 s window.
• Nuvio Max'd (PPSA99288, --trap-sdk-syscall-stubs): [SX] 59.9 fps, worst frame 21.6 ms.

On main c13dc7e all three stop at poll: POLLPRI is not supported by WSAPoll.

[babyhuey]

More titles for this: ProsperoEden (PPSA99008, discussion #4852), PSXS5 (PPSA97510), SwanStationPS5 (PPSA98510) and ProsperoRadio (PPSA99001). On main (Windows 11, catalog releases; ProsperoEden with --trap-sdk-syscall-stubs) each exits with 0xC0000409 on poll: POLLPRI is not supported by WSAPoll, shortly after start-up.

With bf51a20 merged onto main (clean merge), the throw is gone and each runs the full 60 s:

• ProsperoEden (on 7e181fc) draws its launcher at 60 fps. It then stops only for user content (prod.keys, firmware, games).
• On ea2bbef, PSXS5 and ProsperoRadio render at 59.9 fps and SwanStationPS5 at 119.8 fps, with no throws.

[LeandroLP23]

This unblocks four catalog titles on Windows. Windows 11 (26300), Radeon 860M, WinLibs GCC 15.2.0, Release. Head bf51a206c merged onto main 88107b7de. Each title is relinked with --windows --trap-sdk-syscall-stubs and run for 60 s.

Title	main	main + this PR
PSXS5 (PPSA97510)	poll: POLLPRI is not supported by WSAPoll, exit after 9 s	runs 60 s, 32 FPS
SwanStationPS5 (PPSA98510)	same stop, after 8 s	runs 60 s, 29 FPS
ProsperoEden (PPSA99008)	same stop, after 8 s	runs 60 s, 57 FPS
Nuvio Max'd (PPSA99288)	same stop	the UI runs 60 s at 43 FPS

Nuvio Max'd then hits abort() when the run is closed. Its log shows nothing failing before that, and the close comes after the point this PR changes, so I'm noting it, not counting it against the PR.

AI-assisted: yes (Claude Code)

[MarcZX10]

Thanks for the coordination note. #4391 merged on October 13, so the proposed #4525-before-#4391 ordering is now moot; there is no remaining sequencing conflict from that PR. I see #4525 currently reports a conflict with main, so please keep the merged socket-descriptor changes and both groups of GuestPoll tests when updating it.

[oneandonlydean]

Needs a rebase: #4391 is merged and this now conflicts with it in core/libs/prx/libkernel/Socket/src/Udp.cpp and docs/dev/debt/libkernel.md. It gets a full build once it is clean.

[screamm]

Windows validation with title evidence (Windows 11 Pro 26220, WinLibs MinGW-w64 GCC 15.2.0 r7, Ninja, Release, BUILD_TESTING=ON, full build including libs; base main d379bfd0 with #5025 applied for the title runs (without it current main cannot load libkernel_sys.prx on Windows, #4877)): the earlier head bf51a206 merged onto d379bfd0 (two trivial conflicts: main already looks up the socket earlier in Udp.cpp, so the duplicate Find block and main's POLLPRI throw go; the debt sentence applied to main's poll bullet). Code matches my fix/libkernel-poll-pollpri-sockets commit (NativePollIn/NativePollPriority, throw removed); the debt text is shorter. guest_poll 3/3; suite 685/688 with conventions_function_bodies and guest_sce_net passing serially and patched_libraries being main's #4877 failure; conventions and git diff --check pass. The rebased head 5db1d8d5 has the same code, merges cleanly onto 075169f7 and passes conventions, but I did not rebuild it.

Titles (before, main + #5025: all four end with what(): poll: POLLPRI is not supported by WSAPoll at 3 to 5.5 s): with this PR all four run the whole minute with no stop line: PSXS5 FPS: 25.53 (1400), SwanStation FPS: 34.75 (1714), ProsperoTV FPS: 23.63 (686), ProsperoRadio FPS: 21.35 (736) (frame rates lowered by other builds on the host; ProsperoTV/Radio staged with app0/eboot.bin, see #5040).