| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
replace anymore.
|
|
Conflicts:
OpenSim/Region/PhysicsModules/ConvexDecompositionDotNet/Properties/AssemblyInfo.cs
|
|
|
|
scripts reset
|
|
|
|
|
|
specific additions that should not have been there in the first place.
Sleeping and time measurement are now completely internal to XEngine
|
|
The approach is good but the way it is written breaks the architecture.
Rewrite follows.
This reverts commit a568f06b7faea807149205d0e47454e4883e4836.
|
|
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.
|
|
Sleeping doesn't use the CPU.
|
|
The value shown is the number of milliseconds per frame that were spent executing scripts in this region.
|
|
handling it in XEngine
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.
|
|
last 30 seconds. Use a sliding window to calculate this.
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
|
|
(milliseconds) and TimeSpan.TicksPerXXX (10000 x milliseconds)
|
|
of a problem
|
|
AssemblyVersion("0.8.2.*")
|
|
the EventQueue lock to avoid some flags possibly being wrongly set (m_LastControlLevel, etc.)
|
|
are not thread-safe structures.
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()
|
|
http://opensimulator.org/mantis/view.php?id=6960 which should make state changes behave more like is described here http://wiki.secondlife.com/wiki/State
|
|
http://wiki.secondlife.com/wiki/LlGetStartParameter
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
|
|
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
|
|
EventQueue lock in ScriptInstance.SaveState()
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.
|
|
the appropriate script engines subdir is loaded rather than always that of the first engine to load the DLL.
This resolves a DLL load failure on my Linux box when an attachment script was present on another region before the avatar arrived.
|
|
rezzed from inventory (e.g. attachments) was no longer loaded.
Likely a regression since f132f642 (2014-08-28)
Relates to http://opensimulator.org/mantis/view.php?id=7278
|
|
removal by locking on the script's EventQueue and only proceeding if it's flagged as still running.
Relates to http://opensimulator.org/mantis/view.php?id=7407
|
|
one as these are ignored since .state is saved in the attachment's asset.
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
|
|
with an exception. To aid debugging.
|
|
their own or as attachments) with AppDomainLoading = false would create the new state in the source region area rather than the dest.
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
|
|
streams in the script engine even if exceptions are thrown.
|
|
package rather than some in OpenSim.Tests.Common.Mock
the separate mock package was not useful and was just another using line to always add
|
|
that were removed some time ago
|
|
existing session use the previous strategy for that script rather than not starting the script at all.
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.
|
|
|
|
|
|
This resolves http://opensimulator.org/mantis/view.php?id=6936
|
|
|
|
stack unwinding.. the faster it goes.
* Tweak XEngine so that it's partially functional again. It's still not great, but basic things work.
(cherry picked from commit 01c3be27460fd3f28efd17b8d6606b883350f653)
|
|
stack unwinding.. the faster it goes.
* Tweak XEngine so that it's partially functional again. It's still not great, but basic things work.
|
|
|
|
lifetime in order to avoid a later RemotingException if scripts are being loaded into their own domains.
This is necessary because XEngineScriptBase now retains a reference to an EventWaitHandle when co-op termination is active.
Aims to address http://opensimulator.org/mantis/view.php?id=6634
|
|
2.2.3. Remove left in Console.WriteLine accidentally inserted in recent 206fb306
|
|
SmartThreadPool code comes from http://www.codeproject.com/Articles/7933/Smart-Thread-Pool
This version implements thread abort (via WorkItem.Cancel(true)), threadpool naming, max thread stack, etc. so we no longer need to manually patch those.
However, two changes have been made to stock 2.2.3.
Major change: WorkItem.Cancel(bool abortExecution) in our version does not succeed if the work item was in progress and thread abort was not specified.
This is to match previous behaviour where we handle co-operative termination via another mechanism rather than checking WorkItem.IsCanceled.
Minor change: Did not add STP's StopWatch implementation as this is only used WinCE and Silverlight and causes a build clash with System.Diagnostics.StopWatch
The reason for updating is to see if this improves http://opensimulator.org/mantis/view.php?id=6557 and http://opensimulator.org/mantis/view.php?id=6586
|
|
rather than simply ignoring it.
This should never normally happen but if it does then it can be valuable diagonstic information.
|
|
|
|
|
