Since my latest dipping into the UOX3 code, it makes me wonder what could be.
I many times wonder about threads. I have used them in the early days of my career (sub processes), and near the end.
The one thing that is nice, is if they don't have to interact with another thread except on rare occasion. Why I was thinking:
1. Network connection and login. For this to be real effective, player character data would need to be stored/saved outside the world. That would allow only this thread to access it.
Only when a player is ready to "enter" the world, it would be handed off to the the appropriate thread for processing.
2. Keyboard. I suppose so, although I wonder if this shouldn't be combined with some other maintenance (if any is needed).
3. A thread per world (a world per map). A runloop so to speak to address each world/map. Yes, in truth, low population servers, a lot of wasted compute. So perhaps not? Something to ponder.
A thread on demand could be for world saves, but that is a on demand type of thing.
Now, I have toyed with a timer thread(s), and other items (sending out data, reading in packets, etc). Even the concept of scheduling function calls/command in the runloop (std::function to the rescue).
Some interesting posisblities. I have often wondered about sizing, and what the target audience for UOX3 is, and then, what is reasonable if updating thousands of npcs, and hundreds of players.
Oh well, just wanted to capture some thoughts.