• 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.

• Have to be careful to avoid deadlock circumstances.

• 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

put information from the logs of IRC discussion here

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