IN IRQ WE TRUST

I've lived in single-threaded land for the better part of the last decade, after spending a good bit of time experimenting with multi-threaded projects, and mostly deeming it a headache, given the scope of my work. It's usually not worth the hassle, what with single core speeds creeping steadily upward, and memory speed/bandwidth going along for the ride. Debugging multi-threaded applications is a one-way ticket to hell, and I don't care to revisit that.

That said, I'm not entirely opposed to dabbling in some threaded nonsense from time to time. IRQ loaders were pretty popular in the C64 scene, and admittedly I never messed with them. 0xDB got one working a few hours before our first demo landed at Assembly 2015, and we made the call to skip it, just to be safe. I sort of regret that, but it was fun all the same, and people got a good laugh out of the loading screen. But by god, did it take a minute (literally) to load everything. ARGH.

I've stepped back into the pthreads thing and whipped up a dirt-simple background asset loader for my Raylib projects. I'll be dogfooding it with the demo. Right now it consists of a single queue that launches a worker thread to load resources while the main thread continues rendering. Anything the needs to be processed within the main thread (think: OpenGL-specific thingies) gets taken care of there, inside a monitoring routine that checks the status of the queue. Everything else gets loaded inside the worker thread. Atomics make for thread-safe communication between threads.

It's all quite primitive, and because of that, there's no need to mess around with mutexes, locks, etc, beyond the atomics. I could potentially allocate multiple queues with their own threads, and dedicate one to each type of resource (texture, shader, font, sound, music, etc) but so far that hasn't been a priority.