Thank you for the tips (and for writing them down as excellent haddocs at least a decade ago). That’s unfortunately impossible. SDL2 (due to OpenGL on OSX, possibly also on Windows, but I’m not sure if that changed) needs to run on the main thread. Thank you, Apple. Of course, I can stop using any threads except the main thread, just as pragmatic programmers do, and forgo abstraction and isolation of components.
Ah, so what you want for this use case is support for running lightweight threads in a bound thread. The non-threaded RTS does this, but the threaded RTS doesn’t. And there’s a good reason it doesn’t support that: if you make a safe
foreign call from some thread, then the other threads are supposed to keep running (that’s what the threaded RTS guarantees), but we wouldn’t be able to run the bound thread if its OS thread was in a foreign call made by some other Haskell thread.
So the specific tradeoff you’re making here is to give up some of the progress guarantees that you get from the threaded RTS in exchange for being able to schedule lightweight threads on the main thread. That’s fine I suppose. We could still make the threaded RTS the default, it would just mean that specialised use cases like this would need to use --single-threaded
.
Right. I think this is reasonable. There are use cases that the single threaded RTS supports better. But in general the multithreaded one is what most people will want, so making it the default also makes sense.