User Tools

Site Tools


dev_todo:thread_the_server

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:
    1. Lock it's queue
    2. Copy it's queue and clear the original
    3. Unlock it's queue
    4. 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 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 — 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
dev_todo/thread_the_server.txt · Last modified: 2010/09/04 04:27 (external edit)