D417 - Three more HLE fixes from the same diff: thread join, mutex type, audio init
measured - 2026-08-31
Continuing D416 down the hardware-vs-orbistoun divergence list, each confirmed by the verdict flipping when obSCEne re-runs:
scePthreadJoincarries the thread's return value back (orbistoun-kernel,orbistoun-kernel/thread).enter_guest_with_argumentalready returns the guest thread function'srax;spawnnow keeps it in an exit-value map andjoinmakes it available once the host thread ends, soscePthreadJoinwrites the real value through its out-parameter instead of a zero.030-thread/joinpartial -> pass.- Mutex type is honoured
(
orbistoun-kernel/sync).pthread_mutex_initignored the attribute's type and every lock was non-recursive, so a self-trylockalways answered busy. It now reads the type the attribute already stored (ATTR_TYPE): 2 is recursive, 4 is error-checking.try_lockgrew a third outcome - the owner re-taking a recursive lock is locked, a normal one is busy, an error-checking one is a deadlock - whichscePthreadMutexTrylockmaps to0x0/0x8002_0010/0x8002_0016, matching the console's three answers in015-sync/mutex-recursion. sceAudioOutInitsucceeds (orbistoun-audio). The crate declared the audio surface but exposed no implementations, so every call including init fell to the placeholder's non-zero code and090-audio/initialiseread a failed init. Init now answers success - the port calls that would move samples stay unimplemented, because there is no backend and pretending is the D171 shape.
sceKernelCreateSema
(018-relational/handle-fits) was on the list and
deliberately left alone: its verdict differs because hardware
fails it - the console writes past the end of the int - while orbistoun
writes a clean four-byte handle. orbistoun is the more correct of the
two, and matching the quirk would mean writing a bug.
Total across D416+D417 vs the pre-fix run: 516 -> 522 pass, 12
-> 8 partial, 8 -> 6 skip, fails unchanged, plus the
LoadStartModule and mutex measures now matching hardware. Recorded
measured.