| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
This is always available from m_host.LocalId
|
|
|
|
| |
in self item on initialization.
|
|
|
|
|
|
| |
These behave identically to llAttachToAvatar() and llDetachFromAvatar() except that they do not enforce the PERMISSION_ATTACH check
Intended for use in completely controlled dedicated environments where these checks are more a UI hinderance than a help.
Threat level high.
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
false in both if/else branches
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to release locks, resulting in a crippled simulator.
This seems to be a particular problem with ReaderWriterLockSlim, though other locks can be affected as well.
It has been seen to happen when llDie() is called in a linkset running more than one script.
Alleviation here means supplying a ScriptInstance.Stop() timeout of 1000ms rather than 0ms, to give events a chance to complete.
Also, we check the IsRunning status at the top of the ScriptInstance.EventProcessor() so that another event doesn't start in the mean time.
Ultimately, a better solution may have to be found since a long-running event would still exceed the timeout and be aborted.
|
|
|
|
|
|
| |
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
|
|
|
|
| |
command
|
| |
|
|
|
|
|
|
| |
in ScriptInstance.
Swallowing exceptions just leads to more mysterious failures later on.
|
| |
|
|
|
|
|
| |
On resume, we need to place requeue the script for event processing if there are any events on the queue.
Also need to do this under m_Script lock in order to avoid a race
|
|
|
|
|
| |
These aim currently to suspend and resume all scripts.
However, resume isn't currently working due to what looks like a bug in resume functionality itself.
|
| |
|
|
|
|
| |
user knows why they are waiting.
|
|
|
|
|
| |
The only times when ParentGroup might be null is during regression tests (which might not be a valid thing) and when scene objects are being constructed from the database.
At all other times it's not possible for a SOP not to have a SOG parent.
|
|
|
|
| |
This does a tiny bit to reduce code complexity, memory requirement and the cpu time of pointlessly setting this field to the same value in every SOP
|
| |
|
| |
|
|
|
|
|
|
| |
and CHANGED_REGION work.
Fixes Mantix #5214.
|
| |
|
| |
|
|
|
|
| |
race condition.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
These patch should allow people using systems that do not have their locale set to En_US or similar to use OpenSim without suffering effects such as being a million miles up in the air on login.
The problem was caused by parsing strings without forcing that parse to be En_US (hence different decimal and digit group symbols were causing problems).
Thanks very much to VikingErik for doing the legwork on this fix and phacelia for spotting it in the first place.
|
|
|
|
| |
not in a funky debug window.
|