| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
wait handle to script APIs.
APIs don't need to reference any methods on EventWaitHandle
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
individual IScriptInstances for debugging purposes.
Current, state changes and event fires can be logged for individual scripts.
See command help for more details.
|
| |
|
|
| |
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.
|
| |
|
|
| |
Unchecking "Running" box in script editor now persists. This fixes http://opensimulator.org/mantis/view.php?id=6057
|
| |
|
|
| |
This is always available from m_host.LocalId
|
| |
|
|
| |
in self item on initialization.
|
| |
|
|
| |
This is for the top scripts report.
|
| |
|
|
|
|
|
|
|
|
|
| |
measurement period and an idealised frame time.
The previous lines-per-second measurement used for top scripts report was inaccurate, since lines executed does not reflect time taken to execute.
Also, every fetch of the report would reset all the numbers limiting its usefulness and we weren't even guaranteed to see the top 100.
The actual measurement value should be script execution time per frame but XEngine does not work this way.
Therefore, we use actual script execution time scaled by the measurement period and an idealised frame time.
This is still not ideal but gives reasonable results and allows scripts to be compared.
This commit moves script execution time calculations from SceneGraph into IScriptModule implementations.
|
| | |
|
| |
|
|
|
|
| |
it more understandable as to what it is and what it does (hold a thread pool work item for a waiting of in-progress event)
Also add other various illustrative comments
|
| |
|
|
|
|
|
|
|
| |
OnObjectRemoved just once in the UrlModule itself, rather than repeatedly for every script.
Doing this in every script is unnecessary since the event trigger is parameterized by the item id.
All that would happen is 2000 scripts would trigger 1999 unnecessary calls, and a large number of initialized scripts may eventually trigger a StackOverflowException.
Registration moved to UrlModule so that the handler is registered for all script engine implementations.
This required moving the OnScriptRemoved and OnObjectRemoved events (only used by UrlModule in core) from IScriptEngine to IScriptModule to avoid circular references.
|
| | |
|
| |
|
|
|
|
| |
Apart from one obvious bug, this was failing because attempting to serialize the script from inside the script (as part of saving the attachment as an inventory asset) was triggering an extremely long delay.
So we now don't do this. The state will be serialized anyway when the avatar normally logs out.
The worst that can happen is that if the client/server crashes, the attachment scripts start without previous state.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Adding ability to place script engine assemblies outside
the codebase directories.
Uses new [XEngine] option: ScriptEnginesPath = "path_to_assemblies"
Signed-off-by: Melanie <melanie@t-data.com>
|
| |
|
|
|
|
| |
start, and they started at 1 for real values. Whoever changed that enum
to start at 0 should bow their head in shame. They broke the region start
event. This puts it right again. Meow!
|
| |
|
|
|
|
| |
is fully rezzed and all scripts in it are instantiated. This ensures that link
messages will not be lost on rez/region crossing and makes heavily scripted
objects reliable.
|
| |
|
|
|
|
|
| |
It was used. By the API, which is dynamically loaded. So it didn't complain
until it hit Bamboo
This reverts commit 33d5018e94e52cb875bf43bced623bdc6aa41ef0.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
pass script state and assembly again properly. Reintroduce respecting tht
TrustBinaries flag. Changes the interregion protocol! No version bump
because it was broken anyway, so with a version mismatch it will simply
stay broken, but not crash. Region corssing still doesn't work because
there is still monkey business with both rezzed prims being pushed across
a border and attached prims when walking across a border. Teleport is
untested by may work.
|
| | |
|
| | |
|
| |
|
|
| |
to return dynamic method objects
|
| |
|
|
|
| |
Moved the Close() for the appdomain-hosted parts into a new destructor
on ScriptInstance.
|
| |
|
|
|
| |
This matches behavior seen with an earlier attempt to do this, apparently
the sponsor mechanism does't work in Mono
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|Date: Wed, 5 Aug 2009 09:51:52 -0700
|Subject: [PATCH] Closed two major memory leaks for scripted objects
|
|Two major memory leaks for the scripted objects were fixed
|- One leak had to do with remoting acrossing app domains. When a script and
| its controlling agent communicate across an application boundary, it calls
| functions on a stub proxy object that then invokes the remote method on
| the object in the other app domain. These stub objects (two for each script)
| were setup to have infinate lifetimes and were never being garbage collected.
|- The second leak was the result of adding a scene object part instance method
| to a scene event and never removing it. This cause the event's delegate list
| to maintain a link to that object which is then never freed as the scene event
| object is never destroyed.
Patch applied, please direct feedback to me. Possible issue: Longtime idle
scripts like vendors may fail.
|
| |
|
|
| |
Signed-off-by: dr scofield (aka dirk husemann) <drscofield@xyzzyxyzzy.net>
|
| |
|
|
| |
allow final deletion of objects. Meant to support the attach(NULL_KEY) event,
|
