Console command debug xengine now turns that on.
Also, per orenh, remove the triggers at 1000 and 10000 as they are not
useful now that top scripts works.
Previously the script state was never saved for a !Running script, so upon region restart the script would be Running again.
The use of the 'StayStopped' flag is needed because all scripts are automatically stopped when the region shuts down, but in that case we shouldn't save in their state that they're !Running.
Previously the "Net Time" was reported: only the time actually spent in the script's code. This is not a correct indication of how much load the script places on the simulator, because scripts that change state often or have many events use up a lot of time just in the event handlers, and previously this time wasn't counted.
Notes:
- This metric provides a better indication of which scripts are taking up a lot of CPU (and therefore should be optimized).
- Previously the execution time was reset to 0 in every new measurement period, causing the reported time to fluctuate for no reason. This has been fixed by using a sliding window.
1. Use a Stopwatch (a high-resolution timer)
2. Whenever we start a new measurement period, zero out the total execution time (previously it just kept accumulating)
3. Changed the measurement period from 30 minutes to 30 seconds. This is much more useful in the "Top Scripts" dialog, as it shows currently active scripts
This should also make it less likely that an event will be erroneously posted during a state change by precluding a race condition with a thread calling ScriptInstance.PostEvent()
This takes the AsyncCommandHandler.staticLock.
However, AsyncCommandHandler.DoOneCmdHandlerPass() already holds staticLock and may attempt to take the EventQueue lock via ScriptInstance.PostEvent() in XEngine.CheckListeners()
This is a regression from faaf47a (Fri Jan 16 2015) but not simply reverting that commit since it will reintroduce a race between script removal, backup and event queue manipulating code.
This eliminates pointless work and exceptions when an appdomain is unloaded whilst an attachment script state is persisted.
Adds test for this case.
Relates to http://opensimulator.org/mantis/view.php?id=7407
This was beause the code was finding the script DLL compiled for the source region as everything is in the same appdomain and using this as the location for the destination script state, etc.
This resolves the regression by passing the proper destination separately from the DLL retrieved.
Probably a regression since commit d7b92604 (11 July 2014).
Added regression test for this case.
At least partly addresses http://opensimulator.org/mantis/view.php?id=7278
We have to do this since we can't unload existing DLLs if they're all in the same AppDomain.
But we can still update the underlying DLL which will be used in the next simulator session.
