Message boxes on background threads...
I moved iOS's messagebox to SDL_RunOnMainThread() to fix #12741. I'm wondering if we should move this to the higher level and do all message boxes on the main thread, regardless of platform.
It'll probably save some misery on new platforms, and I suspect there are several of these lesser-used platforms (RiscOS, PSP, etc) where this is likely failing/crashing in background threads anyhow and no one has yet noticed.
It also guarantees the SDL event queue is blocked until the message box finishes, which is (probably...?) desirable.
I haven't thought through all the ramifications, though. Just posting here for further consideration.
That's probably not what we want universally. In Source 2 for example, the message box can be launched on a thread and blocks the main thread from the calling code, waiting for it to complete. If someone wants that behavior, they can wrap their own code launching the message box on the main thread. In fact, we could even provide that as an example on the wiki if we want.
I'm sort of the opinion that a message box should block the main thread, as they are kind of stop-the-world from a UI standpoint, and the event loop is now fighting a modal dialog to keep the game running.
But if you feel strongly about it, it isn't hurting anything at the moment, and we can mark this WONTFIX.
Let’s try it in 3.4 and I’ll update Source 2 and see if it becomes an issue
By the way, if a thread pops a message box before the main thread initialization, this would make the calling thread the main thread, so we probably want to only do this if there’s already a main thread.
This is also an issue when using Emscripten. It will crash the app because alert can only be run on the main thread. I've worked around this but I agree with @icculus that a message box should always run on the main thread and block it.