Crossfire Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Threading the server ======
===== Plans/Ideas =====
  * Per-map threads and per-player threads
  * Mutex locks in players, and in 'map queues'.
    * 'map queues' are queues of things for a map thread to do, that it is told to do by other maps.
  * One map thread when wanting to do something such as teleport an object to another map, get a lock on the map's queue and put it in a queue of things for the other map thread to do in it's next tick.
  * In order to avoid all chance of deadlock, do this when processing the queue of things other threads told the thread to do:
    - Lock it's queue
    - Copy it's queue and clear the original
    - Unlock it's queue
    - Process the copy of the queue.
    * Otherwise, there is a small chance that two processing queues at the same time might want to lock eachother to add to the list.
    * Alternatively one could do per-query-entry locking, however that wouldn't work with a linked list, plus that much locking and unlocking may become expensive on cpu
  * Perhaps use the proposed [[dev_todo:unified event system]] to implement the per-map queues.


===== Issues to watch out for =====
  * Have to be careful to avoid deadlock circumstances.

===== Comments =====
  * I consider this to be a very low priority thing, however made the wiki page here to make sure some ideas about implementing it are not lost --- //[[user:rednaxela|Alex Schultz]] 2006/10/09 11:15//

===== More information =====

FIXME put information from the logs of IRC discussion here

===== Nicolas's ideas =====

Things to solve:
  * thread-safety for shared strings ; not too bad
  * thread-safety for freed objects, and active objects
    * solution 1: put'em between mutexes
    * solution 2: each map has its own list ; issue with linked maps, merge the lists?


Things that should definitely be threaded:
  * map loading
    * caveat: players entering a map will be in a "vacuum" during load ; doesn't seem bad
  * map saving
    * caveat: issue with DM command "reset", will need to ensure map is correctly saved


Things that would be nice to thread:
  * one thread per map
    * issue: how will the "Object.Teleport" Python function work, since it couldn't cross thread boundaries? simply remove it, and force script makers to use other means?
    * same issue with ready_map() through scripts - what happens if the map is already loaded and has its thread running?
  * thread for socket processing, one per player maybe
  * ideally, one could thread potentially long operations like massive item selling, or massive item drop
  * thread socket sending to players, to make the previous operations faster?
  * split eg item selling and player notification, with that latter moved to a separate thread