kmx git

Commit	Date	Message
d1eb2d19	2017-02-13T17:05:14	thread: Don't use SetThreadDescription on WinRT right now. Can't LoadLibrary for it, but not sure if it's actually available there yet.
8fa9b57f	2017-01-27T20:50:30	windows: first shot at naming threads with SetThreadDescription(). This is a bleeding edge API, added to Windows 10 Anniversary Edition (build 1607, specifically). https://msdn.microsoft.com/en-us/library/windows/desktop/mt774976(v=vs.85).aspx Nothing supports this yet, including WinDbg, Visual Studio, minidumps, etc, so we still need to also use the RaiseException hack. But presumably tools will use this API as a more robust and universal way to get thread names sooner or later, so we'll start broadcasting to it now.
45b774e3	2017-01-01T18:33:28	Updated copyright for 2017
36156335	2016-11-20T21:34:54	Renaming of guard header names to quiet -Wreserved-id-macro Patch contributed by Sylvain
97aa5775	2016-11-16T22:08:51	Fixed empty parameter list in signatures of internal functions.
57d01d7d	2016-11-13T22:57:41	Patch from Sylvain to fix clang warnings
74e1dd4c	2016-11-11T13:14:00	Define _GNU_SOURCE when building SDL
83cb2b63	2016-10-14T06:57:55	Fixed bug 2758 - Android issues with NDK r10c and API-21 Sylvain After a long time, I found out more clearly what was going wrong. The native libraries should be built with a "APP_PLATFORM" as low as possible. Ideally, APP_PLATFORM should be equals to the minSdkVersion of the AndroidManifest.xml So that the application never runs on a lower APP_PLATFORM than it has been built for. An additional good patch would be to write explicitly in "jni/Application.mk": APP_PLATFORM=android-10 (If no APP_PLATFORM is set, the "targetSdkVersion" of the AndroidManifest.xml is applied as an APP_PLATFORM to the native libraries. And currently, this is bad, because targetSdkVersion is 12, whereas minSdkLevel is 10. And in fact, there is a warning from ndk: "Android NDK: WARNING: APP_PLATFORM android-12 is larger than android:minSdkVersion 10 in ./AndroidManifest.xml".) to precise what happened in the initial reported test-case: Let say the "c" code contains a call to "srand()". with APP_PLATFORM=android-21, libSDL2.so contains a undef reference to "srand()". with APP_PLATFORM=android-10, libSDL2.so contains a undef reference to "srand48()". but srand() is missing on devices with APP_PLATFORM=android-10 (it was in fact replaced by srand48()). So, if you build for android-21 (where srand() is available), you will really have a call to "srand()" and it will fail on android-10. That was the issue. The path tried to fix this by in fact always calling srand48(). SDL patches that were applied are beneficial anyway, there are implicitly allowing they backward compatibility of using android-21 on a android-10 platform. It can be helpful in case you want to target a higher APP_PLATFORM than minSdkVersion to have potentially access to more functions. Eg you want to have access to GLES3 functions (or other) of "android-21". But, if dlopen() fails (on android-10), you do a fall-back to GLES2.
741aaf4c	2016-10-12T22:34:54	Added a note on how to allow non-root applications to increase their thread priority on Linux
27d4f099	2016-10-07T23:40:44	Implemented SDL_GetHintBoolean() to make it easier to check boolean hints
9f854cdb	2016-10-01T10:08:34	Fixed bug 3388 - Fail to build src/thread/windows/SDL_systhread.c on MinGW 4.9.3 Vitaly Novichkov Line 124 ==================================================================== const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION : 0; ==================================================================== Error of compiler: ==================================================================== CC build/SDL_systhread.lo src/thread/windows/SDL_systhread.c: In function 'SDL_SYS_CreateThread': src/thread/windows/SDL_systhread.c:124:45: error: 'STACK_SIZE_PARAM_IS_A_RESERVA TION' undeclared (first use in this function) const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION : 0; ^ src/thread/windows/SDL_systhread.c:124:45: note: each undeclared identifier is r eported only once for each function it appears in make: *** [build/SDL_systhread.lo] Error 1 ==================================================================== Fixing when I adding into begin of the file: ==================================================================== #ifndef STACK_SIZE_PARAM_IS_A_RESERVATION #define STACK_SIZE_PARAM_IS_A_RESERVATION 0x00010000 #endif ====================================================================
92d700f1	2016-09-30T09:26:57	SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING
72dc8784	2016-04-14T21:09:45	PSP: Fixed compile error.
9b9ca093	2016-04-12T18:12:04	windows: created threads' stack sizes should be reserved, not committed.
c61675dc	2016-04-12T16:45:10	threads: Move SDL's own thread creation to a new internal API. This allows us to set an explicit stack size (overriding the system default and the global hint an app might have set), and remove all the macro salsa for dealing with _beginthreadex and such, as internal threads always set those to NULL anyhow. I've taken some guesses on reasonable (and tiny!) stack sizes for our internal threads, but some of these might turn out to be too small in practice and need an increase. Most of them are simple functions, though.
7ae2951f	2016-04-12T14:38:50	threads: Handle SDL_HINT_THREAD_STACK_SIZE at top level, implement elsewhere.
481a21b0	2016-02-21T17:21:29	Windows: Just use WaitForSingleObjectEx() everywhere. (It's supported on WinXP, no reason to have an #ifdef here...I think.)
9fd4d4dd	2016-02-21T17:05:25	Windows: let threads be named in the debugger. We now only raise the magic exception that names the thread when IsDebuggerPresent() returns true. In such a case, Visual Studio will catch the exception, set the thread name, and let the debugged process continue normally. If the debugger isn't running, we don't raise an exception at all. Setting the name is a debugger trick; if the debugger isn't running, the name won't be set if attached later in any case, so this doesn't lose functionality. This lets this code work without assembly code, on win32 and win64, and across various compilers. The only "gotcha" is that if you have something attached that looks like a debugger but doesn't respect this magic exception trick, the process will likely crash, but that's probably a deficiency of the attached program. Fixes Bugzilla #2089.
42065e78	2016-01-02T10:10:34	Updated copyright to 2016
696cd797	2015-12-29T02:32:47	NetBSD: fixed issues with cpuinfo and pthread_setname_np (thanks, Thomas!). Fixes Bugzilla #3176.
fa2d5ab4	2015-11-26T13:51:03	WinRT: bug-fix - SDL_SetThreadPriority() didn't work on WinRT 8.x platforms WinRT 8.0 (Phone and non-Phone) didn't offer an API to set an already-created thread's priority. WinRT 8.1 offered this API, along with several other Win32 thread functions that were previously unavailable (in WinRT). This change makes WinRT 8.1+ platforms use SDL's Win32 backend.
a5a80cd0	2015-11-15T13:04:42	WinRT: fixed crash in SDL_CondWaitTimeout, when using Win10's MSVC runtime
98986f39	2015-08-15T21:21:29	Removed not needed call to pthread_attr_getstacksize() for SDL_CreateThread().
29199056	2015-07-15T21:11:24	PSP: Fixed error handling in SDL_SemWaitTimeout(). Signed integers were converted to unsigned before being checked if smaller 0. Found by Cppcheck.
0e45984f	2015-06-21T17:33:46	Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI().

d1eb2d19

2017-02-13T17:05:14

thread: Don't use SetThreadDescription on WinRT right now. Can't LoadLibrary for it, but not sure if it's actually available there yet.

8fa9b57f

2017-01-27T20:50:30

windows: first shot at naming threads with SetThreadDescription(). This is a bleeding edge API, added to Windows 10 Anniversary Edition (build 1607, specifically). https://msdn.microsoft.com/en-us/library/windows/desktop/mt774976(v=vs.85).aspx Nothing supports this yet, including WinDbg, Visual Studio, minidumps, etc, so we still need to also use the RaiseException hack. But presumably tools will use this API as a more robust and universal way to get thread names sooner or later, so we'll start broadcasting to it now.

45b774e3

2017-01-01T18:33:28

Updated copyright for 2017

36156335

2016-11-20T21:34:54

Renaming of guard header names to quiet -Wreserved-id-macro Patch contributed by Sylvain

97aa5775

2016-11-16T22:08:51

Fixed empty parameter list in signatures of internal functions.

57d01d7d

2016-11-13T22:57:41

Patch from Sylvain to fix clang warnings

74e1dd4c

2016-11-11T13:14:00

Define _GNU_SOURCE when building SDL

83cb2b63

2016-10-14T06:57:55

Fixed bug 2758 - Android issues with NDK r10c and API-21 Sylvain After a long time, I found out more clearly what was going wrong. The native libraries should be built with a "APP_PLATFORM" as low as possible. Ideally, APP_PLATFORM should be equals to the minSdkVersion of the AndroidManifest.xml So that the application never runs on a lower APP_PLATFORM than it has been built for. An additional good patch would be to write explicitly in "jni/Application.mk": APP_PLATFORM=android-10 (If no APP_PLATFORM is set, the "targetSdkVersion" of the AndroidManifest.xml is applied as an APP_PLATFORM to the native libraries. And currently, this is bad, because targetSdkVersion is 12, whereas minSdkLevel is 10. And in fact, there is a warning from ndk: "Android NDK: WARNING: APP_PLATFORM android-12 is larger than android:minSdkVersion 10 in ./AndroidManifest.xml".) to precise what happened in the initial reported test-case: Let say the "c" code contains a call to "srand()". with APP_PLATFORM=android-21, libSDL2.so contains a undef reference to "srand()". with APP_PLATFORM=android-10, libSDL2.so contains a undef reference to "srand48()". but srand() is missing on devices with APP_PLATFORM=android-10 (it was in fact replaced by srand48()). So, if you build for android-21 (where srand() is available), you will really have a call to "srand()" and it will fail on android-10. That was the issue. The path tried to fix this by in fact always calling srand48(). SDL patches that were applied are beneficial anyway, there are implicitly allowing they backward compatibility of using android-21 on a android-10 platform. It can be helpful in case you want to target a higher APP_PLATFORM than minSdkVersion to have potentially access to more functions. Eg you want to have access to GLES3 functions (or other) of "android-21". But, if dlopen() fails (on android-10), you do a fall-back to GLES2.

741aaf4c

2016-10-12T22:34:54

Added a note on how to allow non-root applications to increase their thread priority on Linux

27d4f099

2016-10-07T23:40:44

Implemented SDL_GetHintBoolean() to make it easier to check boolean hints

9f854cdb

2016-10-01T10:08:34

Fixed bug 3388 - Fail to build src/thread/windows/SDL_systhread.c on MinGW 4.9.3 Vitaly Novichkov Line 124 ==================================================================== const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION : 0; ==================================================================== Error of compiler: ==================================================================== CC build/SDL_systhread.lo src/thread/windows/SDL_systhread.c: In function 'SDL_SYS_CreateThread': src/thread/windows/SDL_systhread.c:124:45: error: 'STACK_SIZE_PARAM_IS_A_RESERVA TION' undeclared (first use in this function) const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION : 0; ^ src/thread/windows/SDL_systhread.c:124:45: note: each undeclared identifier is r eported only once for each function it appears in make: *** [build/SDL_systhread.lo] Error 1 ==================================================================== Fixing when I adding into begin of the file: ==================================================================== #ifndef STACK_SIZE_PARAM_IS_A_RESERVATION #define STACK_SIZE_PARAM_IS_A_RESERVATION 0x00010000 #endif ====================================================================

92d700f1

2016-09-30T09:26:57

SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING

72dc8784

2016-04-14T21:09:45

PSP: Fixed compile error.

9b9ca093

2016-04-12T18:12:04

windows: created threads' stack sizes should be reserved, not committed.

c61675dc

2016-04-12T16:45:10

threads: Move SDL's own thread creation to a new internal API. This allows us to set an explicit stack size (overriding the system default and the global hint an app might have set), and remove all the macro salsa for dealing with _beginthreadex and such, as internal threads always set those to NULL anyhow. I've taken some guesses on reasonable (and tiny!) stack sizes for our internal threads, but some of these might turn out to be too small in practice and need an increase. Most of them are simple functions, though.

7ae2951f

2016-04-12T14:38:50

threads: Handle SDL_HINT_THREAD_STACK_SIZE at top level, implement elsewhere.

481a21b0

2016-02-21T17:21:29

Windows: Just use WaitForSingleObjectEx() everywhere. (It's supported on WinXP, no reason to have an #ifdef here...I think.)

9fd4d4dd

2016-02-21T17:05:25

Windows: let threads be named in the debugger. We now only raise the magic exception that names the thread when IsDebuggerPresent() returns true. In such a case, Visual Studio will catch the exception, set the thread name, and let the debugged process continue normally. If the debugger isn't running, we don't raise an exception at all. Setting the name is a debugger trick; if the debugger isn't running, the name won't be set if attached later in any case, so this doesn't lose functionality. This lets this code work without assembly code, on win32 and win64, and across various compilers. The only "gotcha" is that if you have something attached that looks like a debugger but doesn't respect this magic exception trick, the process will likely crash, but that's probably a deficiency of the attached program. Fixes Bugzilla #2089.

42065e78

2016-01-02T10:10:34

696cd797

2015-12-29T02:32:47

NetBSD: fixed issues with cpuinfo and pthread_setname_np (thanks, Thomas!). Fixes Bugzilla #3176.

fa2d5ab4

2015-11-26T13:51:03

WinRT: bug-fix - SDL_SetThreadPriority() didn't work on WinRT 8.x platforms WinRT 8.0 (Phone and non-Phone) didn't offer an API to set an already-created thread's priority. WinRT 8.1 offered this API, along with several other Win32 thread functions that were previously unavailable (in WinRT). This change makes WinRT 8.1+ platforms use SDL's Win32 backend.

a5a80cd0

2015-11-15T13:04:42

WinRT: fixed crash in SDL_CondWaitTimeout, when using Win10's MSVC runtime

98986f39

2015-08-15T21:21:29

Removed not needed call to pthread_attr_getstacksize() for SDL_CreateThread().

29199056

2015-07-15T21:11:24

PSP: Fixed error handling in SDL_SemWaitTimeout(). Signed integers were converted to unsigned before being checked if smaller 0. Found by Cppcheck.

0e45984f

2015-06-21T17:33:46

Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI().

kc3-lang/SDL/src/thread

src/thread

Log