The issue with Thread.Interrupt is that it requires cooperation. Thread.Abort is used precisely to stop non-cooperating scripts from running. Properly written scripts would not need aborting, this is to stop rogue scripts.
They really should fix Thread.Abort. It's understood that locks held by the aborted threads will not be unlocked but the system should not become unstable as a whole because of that. Melanie On 09/01/2013 21:37, Serendipity Seraph wrote: > Forgive me if this question makes no sense as I am not an OpenSim code > expert. But in addition to effectively putting a "should stop" event at the > head of the targeted threads event queue would it also make sense to be able > to find and stop any work and release resources that may be > scheduled/attached on the thread's behalf? Or does that not make sense due > to details of the actual architecture? I can see that it would get tricky to > get the timing right. Also, is there any mechanism to detect locks that > would cause deadlock or waits on things that do not exist or have no > producers? Is it possible to introduce such? > > - s > > On Jan 8, 2013, at 5:42 PM, Justin Clark-Casey wrote: > >> Over the past couple of months, I have been struggling with an issue where >> mono 2.10.8 would sometimes crash badly on a heavily loaded simulator (2000+ >> scripts). Symptoms are 100% cpu use, simulator locking up with all threads >> waiting on a lock which no other thread holds or crashing with native stack >> trace >> >> From analysis, this seems to be due to the use of Thread.Abort() to >> terminate script threads whose events do not complete within a short (or >> sometimes no) timeout. This is used in llDie() and llResetOtherScript(), >> amongst other things. >> >> The use of Thread.Abort() is considered harmful, leading to the kind of >> system instability described above [1] [2] [3], etc. This affects scripts >> running in both separate AppDomains and the same AppDomain, since script >> functions constantly reach into core OpenSimulator code. >> >> One could extend the timeout, but there is a tradeoff with timely script >> stopping. Also, even a large timeout would not guarantee that threads would >> not be aborted. >> >> Therefore, I will probably soon investigate a mechanism for stopping scripts >> without calling Thread.Abort(). This will probably involve the use of >> Thread.Interrupt() for Sleeps and the insertion of 'should I stop' flag >> checks in generated code where that code may be long running (e.g. control >> structures for, goto, etc. and user defined functions). This is the normal >> approach one would take to co-operatively stop threads and avoid the chance >> of leaving Mono/.NET in a bad state. >> >> The existing Thread.Abort mechanisms will remain default until this approach >> is shown not to have significant bugs/problems. However, I think in the >> long term we have to stop using Thread.Abort() by default since it is not a >> safe thing to do. >> >> Comments welcome. >> >> [1] http://stackoverflow.com/questions/1051838/killing-a-thread-c >> [2] http://msdn.microsoft.com/en-us/library/7a2f3ay4%28v=vs.80%29.aspx >> [3] >> http://stackoverflow.com/questions/2251964/c-sharp-thread-termination-and-thread-abort >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
