No complaints from me and thank you for the work done and the testing.

- Melanie

On 15/07/2014 02:17, Justin Clark-Casey wrote:
> Hi folks.  The current method of terminating script threads that do not exit 
> an event in a timely manner is to abort 
> their threads in the VM.
> 
> However, in some cases this can leave the VM unstable, with symptoms such as 
> simulator crash with native stack trace or 
> a leap up to 100% CPU use for no apparent reason.  I experienced these 
> problems myself.
> 
> In response, almost a year and a half ago [1], I implemented an alternative 
> method of script stop ("co-op") that relies 
> on checks inserted at script compile time.  No changes at the LSL level are 
> required.  With this method, the compiled 
> script will always realize that it needs to stop and so no aborts are needed.
> 
> I have used co-op extensively over the last year and a half as have others 
> (e.g. it's used on at least some OSGrid 
> Plazas) without incident and with apparent increased stability.
> 
> It hasn't been default before now because changing to co-op required the user 
> to manually clear their compiled DLL cache 
> or set DeleteScriptsOnStartup = true for one simulator session.  This seems 
> trivial but I felt it would be too 
> disruptive to people who upgrade at release time.
> 
> However, as of git master d7b92604 (11th July 2014), I've implemented a 
> mechanism that will automatically recompile the 
> scripts as necessary and use the new ones on the next simulator restart.  
> Switching the ScriptStopStrategy should now 
> require no further user intervention.
> 
> I've written the details of this up at [2].  Note that switching the stop 
> strategy does not have any impact on saved 
> script variables or other state - scripts will behave as they did before.
> 
> Hence, I now want to switch the default script stop strategy to co-op.  If 
> anybody does want to continue using "abort" 
> for any reason, then this can be done by setting ScriptStopStrategy = abort 
> in the [XEngine] section of OpenSim.ini.
> 
> Please let me know if there are any questions or concerns about this.
> 
> [1] http://opensimulator.org/pipermail/opensim-dev/2013-January/023985.html
> [2] http://opensimulator.org/wiki/XEngine#ScriptStopStrategy
> 
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

Reply via email to