feat(Multistate): Shoehorned multistate#373
feat(Multistate): Shoehorned multistate#373mostlynick3 wants to merge 13 commits intoazerothcore:masterfrom
Conversation
…pstream Eluna Based on parts of azerothcore#249 Co-Authored-By: iThorgrim <125808072+iThorgrim@users.noreply.github.com>
1a7c679 to
ac220f2
Compare
ac220f2 to
9c4051a
Compare
|
Now with full instanced map support as well (BGs, raids, dungeons), with each instance running a separate Lua state :) |
54c0c3c to
4bce66b
Compare
4bce66b to
922302c
Compare
|
So the idea is to have multiple Lua states, but still keep the single map update thread restriction? That is essentially what you'll achieve with the mutex locking, which isn't great. It's definitely better than overriding the map update thread count, but performance/resource wise this is probably going to be worse. |
|
I'm not sure I follow @Foereaper - by "keep the single map update thread restriction", are you referring to there only being one update thread per map? Or possibly just one map update thread in total, effectively, through mutexing? This setup does parallelize load, each map thread gets a separate Lua state that executes its stuff independently of other states. So the map mutexes don't lock other map threads. With this setup, my world update time is reduced by 50% to 75% on theoretical tests like below. That was my goal, after all - ensuring that separate maps' updates do not turn sequential through the world update loop. Did I perhaps misunderstand you? Theoretical test used: |
fe34771 to
21cd9be
Compare
Draft PR for a shoehorned multistate implementation, aiming to replicate "native" multistate without the need for further core-side support/development. Both compatibility mode and multistate mode are working out of the box but I haven't tested in a prod environment yet and thus cannot safely say it's good to go. I assume more changes will be needed.
Anyone is welcome to test it. I've set compatibility mode enabled by default (or, rather, disabled multistate by default), so that on the off chance that this PR gets merged, mod-ale users' existing scripts will work without requiring rewrites.
Note that Data() methods support is not included in this PR as the original Eluna implementation requires core edits to support it. It's of course possible to serialize and store reload-proof data in mod-ale's cache, and thus get Data() support without core edits, but since it's a bit of a hacky solution I've chosen to omit it.