On Sat, 08 Feb 2014 22:50:31 GMT, Dicebot wrote:
Have you read series of articles from extrawurst about his experience of using vibe.d for game server? http://forum.dlang.org/post/dxcruptyfxsaauihzknw@forum.dlang.org
Yes, I have read much of it, and it's good stuff. Need to catch up on parts 3/4 though. His game server is a more suitable candidate for vibe-d as he uses websockets which has persistent connections and streams, whereas my game server will use UDP which does not.
I don't think there are many straightforward advantages from vibe.d architecture for your specific use case but there are no drawbacks either.
For the most part, that's what I came to the conclusion of.
Also I doubt using worker thread with naive locking system will do any benefit, can possibly be even worse than simple single-threaded approach. Multithreading is good when you can minimize locking as much as possible.
The lock system I have in mind should only have minimal waiting. It's not naive. However, it's not implemented yet either – it mainly centers around the receiving a packet from a client should only be able to spawn tasks that modify data particular to that client.
I've thought about it a bit, and at least for the initial stages, I think I'm just going to create an interface for implementing backends for the task spawning system. I'll implement my own back ends: One synchronous, one using function pointers/delegates plainly, one using fibers, and one using vibe-d. I'm unsure if for the non vibe-d backends whether it is worth using libevent for UDP, though. It seems like it is much more useful for things like TCP or monitoring files.