Changing the subject to more accurately note the discussion.. I think there are pros & cons to each approach. And in fact, the end result may be a mix. Clearly, good design, looking at pros & cons, and what would actually be used is needed.
Off the top of my head, these are so pros/cons to each method. I'm sure this isn't a complete list. From what I know of the code (which I know pretty good) I personally think multithreading would be easier to do than multiprocess. Multiple processes pros: - Each map being its own process provides crash resistance - if one map/process crashes, everyone else keeps on playing. - Allows for distributed servers (having a cluster of boxes each running some processes). I do wonder how many folks would really use this however. One use for this could be for experimental/custom maps (connect to someones test server that has a new area, etc). - Don't have to deal with thread locking. - Because of no locking, each individual process may scale better on mulitple cores (no thread contention) Multiple process cons: - Extra overhead of IPC between processes is needed - not just to move objects, but also messages, like shouts, etc. This also means writing new code that doesn't currently exist. - May still need some locking for common files (basically anything stored in the var directory, like highscores, banking, etc) - Would need client (and protocol) updates in addition to server updates. - Can not run as many processes as threads - larger memory footprint for each process (vs thread) so would still need each of these processes to handle multiple maps. - Have potential issue of data consistency - if as suggested in Ryo's message that run time loading of new archetypes/other data is added, keep all processes in sync could be tricky. Multiple process mixed (has both pros & cons): - Need a proxy process to handle communication between client and these processes. Client can keep client access even if a process dies. However, this proxy is a new set of code, and if it does die, all clients lose their connection. Multiple thread pros: - Less code changes - other than creation and deletion of threads, only changes really needed is addition of locks - no new IPC code, client updates, etc. - Much more memory friendly - running 1 thread per map, even if that is 1000 threads, is completely doable. - One could even do multiple threads per map, for example a thread run every 60 seconds that does a backup of the map/player/etc. - Multiple threads still fix problem of meteor shower or other slowdowns - would be limited to that one thread (and thus map) and not hit everyone. - Since all threads share same address space, updates to archetypes/images/whatever while running would just work. Multiple thread cons: - Still limited to a single server - can't run distributed. - If one thread crashes, all threads crash. - Can be harder to debug problems (missing locks could lead to odd state of variables which is hard to pinpoint cause of) Multiple thread other notes: - Even with multiple threads, one could have a very simple proxy process, so that if the server does die, that proxy is still running and can re-connect clients to server when it is up again. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
