Conflict: WaitThreadEnd Signed-Negative Result

Conflict ID: CONFLICT-THREAD-WAITEND-001 · Status: RESOLVED BY MEASUREMENT (measured path)

Question

What should an outer sceKernelWaitThreadEnd return when an intermediate joiner carries a signed-negative exit status?

Claims in conflict

• A — Nakagawa / tested PPSSPP: the second-order wait returned 0x800201ac (THREAD_TERMINATED).
• B — PSP-3001 / 6.61-ARK: the same synchronized path returned 0x800200d2 (ILLEGAL_ARGUMENT).

Why they appeared incompatible

Nakagawa and PPSSPP agreed, but the hardware result differed. Their agreement is not independent replication because implementations and historical tables may share lineage.

Resolving experiment

EXP-THREAD-WAITEND-20260805-A synchronized the joiner, emitted raw scalar values, and added positive, explicit-exit, PSP-error-shaped, and ordinary -17 controls.

Smallest supported conclusion

For the measured shared non-delete ThreadMan boundary, signed-negative intermediate exit status is observed as 0x800200d2; positive status is preserved. This is not a universal rule for delete, unload, every wait path, every model, or every firmware.

What was superseded

The older broad assumption that the raw negative/termination-shaped value always propagates through the outer wait is superseded for this measured scope. The earlier unsynchronized READY-state probe remains rejected instrumentation, not deleted history.

Remaining uncertainty

Exit/delete lifecycle, status-bit meaning, cross-model and cross-firmware behavior, and stock-firmware mediation remain open. See EXP-THREAD-UID-REUSE-001 and the ThreadMan reference.

Related finding: FIND-THREAD-NEGEXIT-001. Last reviewed: 2026-08-11.

Current source anchor — Wave 4

The implementation side of this comparison was refreshed against src/rt/sched.c at main 04daf156 and src/rt/hle.c at the same revision.