SDL_CreateThread -- Creates a new thread of execution that shares its parent's properties.
#include "SDL.h" #include "SDL_thread.h" SDL_Thread *SDL_CreateThread(int (*fn)(void *), void *data);
SDL_CreateThread creates a new thread of execution that shares all of its parent's global memory, signal handlers, file descriptors, etc, and runs the function fn passing it the void pointer data. The thread quits when fn returns.
(SDL 1.2.7) Even after the procedure started in the thread returns, there still exist some resources allocated to the thread. To free these resources, use SDL_WaitThread to wait for the thread to finish and obtain the status code of the thread. If not done so, SDL_CreateThread will hang after about 1010 successfully created threads (tested on GNU/Linux). This is consistent with POSIX threads behavior where unless threads are explicitely detached using pthread_detach() or created using a pthread_attr initialized using pthread_attr_setdetachstate() passed at pthread_create(), they must be waited for using pthread_join() for their resources to be released. The SDL threads abstraction library does not provide the functions to detach a thread to launch a thread in detached mode.
(SDL 1.2.9) On win32 (this wasn't observed on unix), the initial thread must be the one polling the SDL events. Otherwise, keyboard events are no longer caught. Moreover, it is recommended to use SDL_mixer and SDL blitting functions from within that initial thread as well, otherwise the system becomes unstable (also only under win32) despite the proper use of mutexes and conditional variables. This unfortunately limits a lot the usefulness of threads when the software is also expected to run on win32.
(SDL 1.2.8) On win32, keystrokes are caught in correctly in a thread, but SDL_EnableUNICODE does not work correctly. Specifically, .unicode contains the same value as .sym, not the modified version for SHFT, CTRL, etc.