The MSpawnScripts mutex competes with individual script mutex's, eg we can hit the RunScript for a spawn, then the mutex is locked for that script, then destroy scripts is called, MSpawnScripts gets locked first, the RunScript can get stuck inbetween needing a MSpawnScripts read lock...
The MSpawnScripts mutex competes with individual script mutex's, eg we can hit the RunScript for a spawn, then the mutex is locked for that script, then destroy scripts is called, MSpawnScripts gets locked first, the RunScript can get stuck inbetween needing a MSpawnScripts read lock...
so revisiting this I noticed we delete the entire luainterface pointer we have which is externally used everywhere.. that won't really work well in this design
Instead the /reload luasystem -- which I think it was originally created for, was to reload all LUA subsystems (all scripts, spawns, items, etc) so I will have it perform that.
so revisiting this I noticed we delete the entire luainterface pointer we have which is externally used everywhere.. that won't really work well in this design
Instead the /reload luasystem -- which I think it was originally created for, was to reload all LUA subsystems (all scripts, spawns, items, etc) so I will have it perform that.
image
The MSpawnScripts mutex competes with individual script mutex's, eg we can hit the RunScript for a spawn, then the mutex is locked for that script, then destroy scripts is called, MSpawnScripts gets locked first, the RunScript can get stuck inbetween needing a MSpawnScripts read lock...
having issues replicating this on demand plus it only happens on /reload luasystem which is an intensive command so only in a dev setting not 'live'
so revisiting this I noticed we delete the entire luainterface pointer we have which is externally used everywhere.. that won't really work well in this design
Instead the /reload luasystem -- which I think it was originally created for, was to reload all LUA subsystems (all scripts, spawns, items, etc) so I will have it perform that.