So it looks like from here:

- App calls SDL_CreateThread*
- SDL_CreateThread allocates some data, creates a semaphore, calls into SDL_SYS_CreateThread
- SDL_SYS_CreateThread spins a thread and calls SDL_RunThread on the new thread, and returns to SDL_CreateThread*
- SDL_CreateThread waits on the semaphore.
- SDL_RunThread sets up some stuff, posts to the semaphore, and calls the app's actual thread entry point.
- SDL_CreateThread sees the semaphore has posted, takes this as an indication that it's safe to free the data it allocated.

...is there any reason we can't do this:
- Don't create a semaphore at all.
- SDL_RunThread frees the data before calling the app's entry point.
- SDL_CreateThread frees the data if SDL_SYS_CreateThread fails, otherwise it leaves it alone.

This means SDL won't have to create a semaphore and won't have to wait for the new thread at all.

The other benefit: Emscripten with pthread support doesn't actually create the thread until the next iteration through the mainloop, so it _can't_ safely wait here by default, as the thread will never post to the semaphore because the thread won't be created at all until some time after SDL_CreateThread returns.

All this to say: is this a _safe_ change to make, or was the semaphore approach done for a specific reason?

--ryan.