Delete src/thread/n3ds/SDL_syscond.c

[ds-sloth]

This PR removes the incorrect specialized implementation of SDL_cond currently included with the 3DS port, allowing the generic implementation to be used.

Description

Pseudocode of the incorrect implementation of SDL_CondWait this PR removes:

• Receive an SDL_cond backed by a libctru CondVar and an SDL_mutex backed by a libctru RecursiveLock.
• Want to call libctru function CondVar_Wait which expects a CondVar and a LightLock (non-recursive lock)
• Do so by calling this function with the internal (inadequately protected) LightLock member of the RecursiveLock (&mutex->lock.lock on line 105), without updating any internal thread or lock count fields of the RecursiveLock.

Happy to discuss or test some examples. My own use case works much better with the generic cond logic, and this seems like a safe fix to me given that the generic logic is well-tested and this seems not to be.

If you like the PR I'll send another one for the SDL2 branch.

[ds-sloth]

Sorry for the failed build -- for some reason our CMakeLists.txt files were out of sync and I didn't think to check the upstream one before starting the PR given that this seemed like a trivial change.

[ds-sloth]

Just looked at the history some, and now I understand -- #8741 postdated #6251. I guess this PR is just finishing #8741's work on 3DS.

[madebr]

@FtZPetruska what do you think about this?
(you added n3ds to SDL in #6251)

[FtZPetruska]

If it works better without, go ahead and get rid of that specialisation!

For the background of this file... Well I simply brought it over from the SDL 1.2 port since there didn't seem to be any difference between the two 😅

[ccawley2011]

For the background of this file... Well I simply brought it over from the SDL 1.2 port since there didn't seem to be any difference between the two 😅

There do appear to be some differences - in particular, the SDL 1.2 version clears the RecursiveLock before waiting on the condition variable and restores it afterwards, while SDL2 and SDL3 don't.

If applying that change doesn't fix the problem, it would probably be best to submit a bug report to libctru rather than replacing the use of CondVar in SDL.

[madebr]

For reference, we had a recent pr suggesting to remove ps2 timers.
It was refused because the posix timers perform worse on that platform.
See #11679

[ds-sloth]

The SDL 1.x code may have been appropriate for something internal to devkitPro, but a client library reaching into the internals of the RecursiveLock isn't particularly safe, even if it technically "works".

I wonder whether anyone here can speak to the performance characteristics of the generic SDL_cond implementation?