Oh, I didn't notice that my goal wasn't clear. Yes, I want a blocking loading process. Before the level loads, the player can do nothing, as the game is loading. I just brought up the whole threaded shenanigans because I envisioned an animated loading screen, so that the player knows the program is alive, but at the same time, I wanted it to have a minimally consistent framerate.
Also, the content I load is varied. Images can go from spritesheets to be used by user-created enemies, to textures used in user-created maps, to static HUD images, to variable particle images. Plus I also load sounds, different types of text files, and more.
But threading would just be overkill, and raise all the silly problems written in this topic.
A static screen works at the moment (specially because it currently takes around a second, so no worries), but if I expand upon this in the future, I'll likely go with a single-threaded solution, probably like Edgar or m c said. Although that would again raise the complexity a bit, in that I'd have to find a way to uniform the loading process for any and all sorts of bitmaps I load, which are quite varied. Plus I'd have to find some way to control how much of the timer tick's time I have left, so I can judge what images to load before I have to render the screen.
It really looks I jumped in on the "different thread" idea far too early. And for quite a while, I couldn't grasp the idea of having a loading process while drawing. And then I realized that the normal game logic does pretty much that, except replace "loading" with "logic". Although on the other hand, a game tick's logic procedure runs in pretty much constant time, whereas content loading might not (one texture can be 32x32, while the next can be 800x800).
I have to apologize, I completely failed to realize that deep down, you were suggesting normal solutions to combat my over-complicated ideology!