Convert ticks to 64-bit, added nanosecond precision to the API #6734
Conversation
|
@FtZPetruska, @mupfdev, @isage, can you take a look at my timing and threading changes here for your platforms? |
|
Looks ok to me |
|
As far as I can apparently tell, everything looks OK. |
…rom the public API It's not clear applications need this level of precision yet, so let's leave these private for now.
| LightSemaphore_Acquire(&sem->semaphore, 1); | ||
| retval = 0; | ||
| } else { | ||
| int return_code = LightSemaphore_TryAcquire(&sem->semaphore, 1); | ||
| if (return_code != 0) { | ||
| /* FIXME: Does this code guarantee a wall clock timeout here? |
There was a problem hiding this comment.
Since there isn't a function to wait on a LightSemaphore, this was just a hack to simulate it.
The 3DS seems to allow for sub-millisecond delays, so we could have:
Uint64 timeout = SDL_GetTicksNS() + timeout;
while (SDL_GetTicksNS() < timeout) {
/* Try acquire semaphore */
/* SDL_DelayNS(1)? */
}In the best scenario, SDL_DelayNS(1) takes about 9-10µs.
Other than that, the rest works great!
There was a problem hiding this comment.
I wasn't sure if that short of a wait might starve whatever code would release the semaphore, but I can certainly change it to that if you want.
…re possible Currently implemented for Windows and Apple platforms
|
Ah, Perfect! I was just about to ask for a "get nanoseconds" function. Timing is one of the few places where I usually ignore SDL's functionality and look elsewhere. This is great. |
Existing Issue(s)
#1000
#5512
#6602
#6731