Issue with `sleep` function about ps2sdk HOT 7 CLOSED

Ping @davidgfnet and @uyjulian to be the most experts on this area

from ps2sdk.

I have tried reverting https://github.com/ps2dev/ps2sdk/pull/470/commits and it looks to works fine, so it must be an issue introduced there:

Bigger diff: 22, requested: 10395, got: 10417

from ps2sdk.

nanosleep says https://man7.org/linux/man-pages/man2/nanosleep.2.html

nanosleep() suspends the execution of the calling thread until either at least the time specified in *req has elapsed

So this would be conformant behavior either way, but more accuracy is better

from ps2sdk.

nanosleep says https://man7.org/linux/man-pages/man2/nanosleep.2.html

nanosleep() suspends the execution of the calling thread until either at least the time specified in *req has elapsed

So this would be conformant behavior either way, but more accuracy is better

While being technically correct I have never seen anything like this in any Posix compatible system under low load. I don't have the proceedings anymore, but I think this provision was added to cover for systems under load where a timely scheduling after the timer expires isn't guaranteed.

from ps2sdk.

Seems like a regression to me.
Just for sanity checking it would be great to validate that clock_gettime is not returning garbage every now and then (it likely won't but better safe than sorry!)

from ps2sdk.

Seems like a regression to me. Just for sanity checking it would be great to validate that clock_gettime is not returning garbage every now and then (it likely won't but better safe than sorry!)

I have specifically checked that, and it looks to work fine, as I did a similar example, this time instead of putting a usleep in the middle, I put a function to generate the first X prime numbers, and the values look to be right too.

from ps2sdk.

I inspected the code and I think it might be related to the timer overflow handling. That ApplyOverflow and its being called several times in the timer irq looks suspicious to me.

from ps2sdk.