Strange semaphore behaviour

[Fanjita]

Quick question : has anyone ever seen anything like this before:

I create a semaphore using

Code: Select all

lrc = sceKernelCreateSema("name", 0, 0, 10, 0)

(actually directly via the syscall, rather than via the SDK)
expecting to create a simple semaphore with 10 max count, 0 initial.

lrc seems to return a sensible number - generally around the 0x04600000 range, a different number each time, so it looks like a plausible SceUID.

But any time I attempt to do anything with that semaphore (signal, wait, referStatus) the operation fails - waits just complete immediately, referStatus doesn't change the sceKernelSemaphoreInfo structure at all - but still returns a successful return code (where applicable).

I can't understand what's going wrong - any advice?

[Fanjita]

Curiouser and curiouser.

It seems that this thread (which I think is the VSH_GRAPHICS_THREAD) doesn't respond to many requests to stall itself.

When I attempt sceKernelSleepThread(), I get the error code SCE_KERNEL_ERROR_ILLEGAL_CONTEXT.

Is there a class of thread (perhaps via thread attributes) that is enforced as non-blocking? Or perhaps a context such as interrupt handler in which blocking is not allowed?

I need to be able to stall this thread somehow, in a recoverable way, as I'm trying to enable clean return from the EBOOT loader to the VSH, using Abu's HELLO2 ideas - and if I don't stall this thread, it keeps messing with the display.

[mrbrown]

My guess would be that only threads in the same class (user, VSH, or USB/WLAN) can manipulate other threads in that class. If that's not the case then it's possible that VSH threads take precedence over user threads.

[Fanjita]

I don't think that can apply, since all my threads are actually VSH (as they hijacked the VSH's TIFF display thread in the first place, and I preserved those attributes during thread creation).

It definitely seems that the thread is defined as non-blocking in some way.

[mrbrown]

Ah... I see what you mean. Sorry, no ideas here that wouldn't require digging into the kernel :).

[Vampire]

... as I'm trying to enable clean return from the EBOOT loader to the VSH...

have you tried sceKernelExitGame (or sceKernelExitGameWithStatus)
or maybe you can use vshKernelExitVSH or vshKernelExitVSHVSH

[Fanjita]

... as I'm trying to enable clean return from the EBOOT loader to the VSH...

have you tried sceKernelExitGame (or sceKernelExitGameWithStatus)
or maybe you can use vshKernelExitVSH or vshKernelExitVSHVSH

The problem is that the loader is running within the scePafJob thread, rather than within a standard EBOOT environment. So I don't believe that ExitGame() will work (though I haven't tried it).

Any idea what ExitVSH actually does? If it provides a way to restart VSH, then that would be perfect.

At the moment, I'm trying to hang the VSH threads while the loader runs in a new thread, then restart them once I'm done. Otherwise, they interfere with the display while the loader is trying to run.

All this is based on Abu's HELLO2 source, which allows you to use the TIFF exploit to launch a new thread, then repair the stack and return the VSH threads as if nothing happened.

[Fanjita]

Well, I managed to get a nasty hack working - freezing the VSH, running a simple app with full control of the screen + input, then returning to VSH as if nothing had happened at the end.

It's all a little ugly, and now I think I'll abandon it in favour of the far simpler solution using sceExitGame().

But if anyone is interested in the source, let me know and I'll post it. It was an interesting exercise, if nothing else.

P.S. I never got to the bottom of the semaphore issue. I suspect it may have been a dispatch thread, although I can't find much info about them. In the end, I found a solution that avoiding having to freeze the particular thread that was behaving oddly (SceWaveMain, I believe).

[Zigo]

Are you using timeouts in sceKernelWaitSema? I am using 0 or NULL for the last parameter and the semaphores seem to be working perfectly (signal and wait). I have not tried out sceKernelReferSemaStatus though.

[Fanjita]

I was using zero (infinite) timeouts.

Both WaitSema and WaitSemaCB were failing.