LWP_CondTimedWait claims to take an absolute timeout, but it doesn't.

[AliceLR]

The documentation for this function should probably be fixed.

The documentation where it claims to take an absolute timeout.
Relevant header file.

However, following the actual implementation...
LWP_CondTimedWait
__lwp_cond_waitsupp
__lwp_wd_insert_ticks
...shows that it is used as a relative timeout.

Places where people have been confused by the wrong documentation of this function.
A user on the devkitPro forums posted about this in 2014.
SDL Wii had to fix their implementation of SDL_CondWaitTimeout in 2015 (issue apparently reported in 2013).
It confused me too.

[DacoTaco]

Hi @AliceLR,

sorry for the long delay in response! just going through the issues atm.
this looks to be an easy fix as its just documentation changes.
would be be fine to rename the abstime to something else? i can't think of a short name for relative time but maybe reltime is better and have the absolute removed?

EDIT : wintermute pointed out that pthread_cond_timedwait uses abs time, and therefor the lwp code should be fixed to use abs time if we were to ever implement pthread for gc/wii. its therefor the other way around sadly >_<

[WinterMute]

Well, what I said was "pthread_cond_timedwait uses abs time. I wonder if we should fix the function to match docs not the other way round". I wasn't suggesting that we should do that, merely looking for consensus on relative vs absolute time here.

It does seem that relative timeouts are more natural and we could, of course, convert to absolute time in our pthread wrappers when we sort that out.