I saw SDL_WaitEventTimeout uses Sint32 for the timeout param, so I assumed if it was a negative it’d return false, but it never returned at all. It’s not hard to write max(0, mytimeout), or include a short circuit in the if, but I rather not need to remember. Is this a bug or desired behavior? I’m running x11 linux
FYI I don’t care if it might return events (or never returns any) before returning false, but I do care about accidentally blocking forever.
A negative timeout number sets the wait to be infinite until some event pops up in the queue.
I think this stems from the idea that time only moves forward, so any negative timeout is impossible, therefore infinity makes more sense. Someone might be able to explain that better.
(Actually the timer gets set to SDL_MAX_SINT64, but that’s a very, very long time).
If I’m reading the source code correctly, there’s mention that enabling a sensor or joystick/gamepad will likely cause the timer to break early in order to poll the device states properly, often once every second or so, at which time the function returns false.
In a normal run, if everything runs correctly, and if there is an event within the timeout the function returns true. If no event occurs in that time it also returns false.
I would consider SDL_WaitEventTimeout to be unreliable as a true timer, but useful as a way to reduce CPU cost while user interaction is low or not existent. It is also nice to have a form of delay that the user can break through device interaction.
Depending on your needs, you might be interested in using SDL’s timer API or SDL_DelayNS instead.
Side note: SDL_PollEvent actually calls SDL_WaitEventTimeout with a timeout of zero, and the result is then directly returned by SDL_PollEvent to say whether events were or were not available.
I think treating negative timeouts the same as 0 would have been the most intuitive behaviour, but it might also be useful to be able to specify infinite timeouts…
It’s not documented that negative values lead to infinite timeouts but when looking at the code there is no doubt that they intended it to work like that.
If the parameter type had been unsigned then passing -1 would overflow to the largest possible value, which is as close to an infinite timeout that you could get, so I guess it makes some sense to allow that.
The timeout behaviour of SDL_WaitEventTimeout is consistent with the poll function in Linux/POSIX.
poll(2) - Linux manual page
Specifying a negative value in timeout means an infinite timeout.
It’s not documented that negative values lead to infinite timeouts but when looking at the code there is no doubt that they intended it to work like that.
That’s correct, and I’ve updated the documentation.
Thanks!