[crossfire] multithread vs multi process

[Mark Wedel]

  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.