This doesn't _suppress_ the warnings, it annotates our memory access pattern
so ThreadSanitizer knows that threads aren't in conflict, since TSan doesn't
know about io_uring's mechanisms.
Fixes#15083.
External window surfaces can't be destroyed and recreated, so try our best to reconfigure them when switching between GL profiles, or between GL and Vulkan.
- Addresses issue #15115
- mach_absolute_time can be misused for fingerprinting. This is bad.
- Apple docs prefer clock_gettime_nsec_np(CLOCK_UPTIME_RAW) in time.h
- Since HAVE_NANOSLEEP is defined, time.h is included
Before, MetalFence was implemented as simply a busy loop on an atomic
int on metal, meaning the cpu would busy wait on the gpu to finish
taking power from it and decreasing battery life. This was the only kind
of cpu-gpu syncing (apart from requesting a swapchain)
The HIDAPI backend table used function pointers that didn't match the
macro-renamed backend function types, which trips Clang's function sanitizer.
Adding small wrappers so the backend table has the correct function types and
the cast to the backend-specific device type happens inside a direct call.
fixes#15821.
in SDL2 SDL_ThreadID() was a function that's now
SDL_GetCurrentThreadID(), but in SDL3 SDL_ThreadID is a type, so
in C++ `x = SDL_ThreadID()` is valid code (default constructor which
in case of integers means 0), so that's a massive footgun.
See the big comment in SDL_oldnames.h for more details.
Added `#undef SDL_ThreadID` in SDL_dynapi.c because it has one of the
(quite rare) cases where "SDL_ThreadID" followed by a "(" is actually
correct and necessary (function pointer returning SDL_ThreadID).
GetTempPath2() is only available on Windows 11 and Windows 10 systems with full updates. We want to be compatible back to earlier versions of Windows and the only difference between the two calls is the behavior for processes running as SYSTEM, which we don't expect for SDL applications using notifications.
It does better version checking and has better compatibility.
This also fixes a crash in GameInputRedist.dll when attempting to load v3 when v2 is installed on the system. In this case, a thread is created in GameInputCreate() which is not cleaned up when the object is released, and can crash later with a NULL pointer dereference.
Otherwise, a device that is disconnected in the standard audio device thread
might keep failing WaitDevice() in a tight loop, each one generating a new
main thread callback. In normal situations, this is wasteful, but if the
app isn't pumping the event loop quickly (or at all!), this will quickly eat
up all the memory in a machine.
Now we note that the device is zombified right away, and device thread
iteration will use this to replace the implementation with the Zombie
equivalents once it owns the device lock.
The main thread callback will progress to device->zombie==2, which it uses to
decide if this is a duplicate disconnect notification. Since it also owns the
lock at this point, it takes the moment to set the Zombie implementation up,
too.
This allows things (like the WASAPI backend) to check for a non-zero zombie
state immediately without having to worry if the main thread callback ran, and
for the standard audio threads to also move to the Zombie implementation
without waiting on that callback.
(The Zombie implementation is used to make a dead device keep processing, so
things that need the audio device to make progress to function will keep
working, and things blindly pushing to an audio stream won't queue up endless
data that isn't being consumed.)
Fixes#15745.
