| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
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.
|
| |
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
avoid a Windows casting issue in SmartThreadPool for large TimeSpans.
TimeSpan.Milliseconds is an int64. However, STP casts this to an int (32-bit).
If TimeSpan.MaxValue is given then the casting results in an invalid value for the SDK WaitHandle.WaitAll() call.
This was causing the co-op script termination regression tests to fail on Windows but not Mono 2.10.8 (which is perhaps not strict in the negative values that it accepts).
Solution here is to use the int millisecondsTimeout STP call rather than the TimeSpan one.
This also allows us to more clearly specify Timeout.Infinite rather than TimeSpan.MaxValue
Thanks to Teravus for this spot.
|
| |
|
|
| |
deprecated in later .net versions
|
| |
|
|
|
|
|
|
| |
fails to load.
Moves the noise co-op start/stop debug log messages to only display if xengine debug level >= 1
Logs which stop strategy is being used (abort or co-op)
Adjusts some other logging to remove not very useful stuff
|
| |
|
|
|
|
|
|
|
| |
continue to generate C# that is functionality identical to historical generation
This is to eliminate disruption until co-op termination has been well-tested.
In non co-op mode, XEngine will continue to load DLLs of the existing Script class and the new XEngineScript class.
Moving to co-op mode still requires existing script DLL deletion to force recompilation, either manually or by setting DeleteScriptsOnStartup = true for one run.
This change also means that scripts which fail to initialize do not still show up as running scripts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
addition to termination on wait.
This involves inserting opensim_reserved_CheckForCoopTermination() calls in lsl -> c# translation at any place where the script could be in a loop with no wait calls.
These places are for, while, do-while, label, user function call and manual event function call.
Call goes through to an XEngineScriptBase which extends ScriptBase.
IEngine is extended to supply necessary engine-specific parent class references and constructor parameters to Compiler.
Unfortunately, since XEngineScriptBase has to be passed WaitHandle in its constructor, older compiled scripts will fail to load with an error on the OpenSim console.
Such scripts will need to be recompiled, either by removing all *.dll files from the bin/ScriptEngines/<region-id> or by setting DeleteScriptsOnStartup = true in [XEngine] for one run.
Automatic recompilation may be implemented in a later commit.
This feature should not yet be used, default remains termination with Thread.Abort() which will work as normal once scripts are recompiled.
|
| |
|
|
|
|
|
|
|
|
| |
script wait event (llSleep(), etc.)
This makes use of EventWaitHandles since various web references indicate that Thread.Interrupt() can also cause runtime instability.
If co-op termination is enabled, then termination sets the wait handle instead of waiting for a timeout before possibly aborting the thread.
This allows the script to cleanly terminate if it's in a llSleep/LL function delay or the next time it enters such a wait without any timeout period.
Co-op termination is not yet testable since checking for termination request within loops that never trigger a wait is not yet implemented.
This commit, unlike 1b5c41c, passes the wait handle as an extra parameter through IScript.Initialize() instead of passing IScriptInstance itself.
|
| |
|
|
|
|
|
|
| |
during a script wait event (llSleep(), etc.)"
Doing this as a favour to Melanie. This will be back with passing the wait handles directly to the api.
This reverts commit 1b5c41c14ad11325be249ea1cce3c65d4d6a89be.
|
| |
|
|
|
|
|
|
|
| |
script wait event (llSleep(), etc.)
This makes use of EventWaitHandles since various web references indicate that Thread.Interrupt() can also cause runtime instability.
If co-op termination is enabled, then termination sets the wait handle instead of waiting for a timeout before possibly aborting the thread.
This allows the script to cleanly terminate if it's in a llSleep/LL function delay or the next time it enters such a wait without any timeout period.
Co-op termination is not yet testable since checking for termination request within loops that never trigger a wait is not yet implemented.
|
| |
|
|
|
|
|
|
| |
pass down IScriptInstance instead.
This is to allow the future co-operative script thread terminate feature to detect and act upon termination requests.
This splits the assembly and state loading out from the ScriptInstance() constructor to a separate Load() method
in order to facilititate continued script logic regression testing.
|
| |
|
|
| |
instead of sometimes but not always looking it up.
|
| |
|
|
|
|
|
|
| |
reset (as called by llResetOtherScript()).
As with script stop (via llDie()) aborting other scripts event threads, llResetOtherScript() can also abort any current event thread on another script.
On mono 2.6, 2.10 and possibly later this may cause locking problems in certain code areas.
This commit reuses the recently introduced [XEngine] WaitForEventCompletionOnScriptStop to make this a 1 sec timeout, rather than 0 secs.
|
| |
|
|
|
|
| |
because they failed to complete event processing within the given timeout.
This is for bug hunting purposes where thread aborts may be causing dangling lock issues and subsequent vm crashes on mono (with ReaderWriterLockSlim, etc.)
|
| |
|
|
|
|
|
| |
individual IScriptInstances for debugging purposes.
Current, state changes and event fires can be logged for individual scripts.
See command help for more details.
|
| |
|
|
|
|
|
|
| |
we also get timestamps.
This commit also adds script name, part name, uuid, etc. for later identification.
This information has been sent to console since 2009 but may be turned down if it proves too noisy.
However, I still currently need it to investigate some region problems probably triggered by scripting.
|
| |
|
|
| |
callers to lock and directly inspect the EventQueue
|
| |
|
|
| |
information and display in "show scripts" for debug purposes
|
| | |
|
| |
|
|
|
|
| |
A better solution using the already present flags must be found.
This reverts commit 6d3ee8bb39d47ed7b32e8905fa0b2fc31c5a9f80.
|
| |
|
|
|
|
| |
the BOM, use a single Util.UTF8NoBomEncoding.
This class is thread-safe (as evidenced by the provision of the system-wide Encoding.UTF8 which does not suppress BOM on output).
|
| |
|
|
|
|
|
| |
constructing fresh copies.
The encodings are thread-safe and already used in such a manner in other places.
This isn't done where Byte Order Mark output is suppressed, since Encoding.UTF8 is constructed to output the BOM.
|
| |
|
|
| |
Unchecking "Running" box in script editor now persists. This fixes http://opensimulator.org/mantis/view.php?id=6057
|
| |
|
|
|
|
| |
loading fails.
Drop logging about memory limit exceeded to warn from error
|
| | |
|
| |
|
|
| |
retrieving state (e.g. exceeds memory limit)
|
