[Opensim-dev] Thread.Abort() considered harmful

[Serendipity Seraph]

Part of fixing Thread.Abort is to release any locks that it may hold as that is a large part of what damage aborting a thread can cause.   Without releasing such locks anything else waiting on them will wait forever and hold whatever locks and resources it has forever or until crash or reboot, whichever comes first.

- s

On Jan 9, 2013, at 2:02 PM, Melanie wrote:

> 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
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> 
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> 
>> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev