diff options
| author | Justin Clark-Casey (justincc) | 2012-12-07 00:47:04 +0000 |
|---|---|---|
| committer | Justin Clark-Casey (justincc) | 2012-12-07 00:47:04 +0000 |
| commit | 0568c76a8801408665730702c97717d3c05cfe4d (patch) | |
| tree | 9d52df990ff6b0b0f51430f1adc1bb7185ab41e1 /OpenSim/Region/Framework/Scenes/SceneCommunicationService.cs | |
| parent | minor: change method doc on GetTextureHandler.TryParseRange(), mainly to trig... (diff) | |
| download | opensim-SC_OLD-0568c76a8801408665730702c97717d3c05cfe4d.zip opensim-SC_OLD-0568c76a8801408665730702c97717d3c05cfe4d.tar.gz opensim-SC_OLD-0568c76a8801408665730702c97717d3c05cfe4d.tar.bz2 opensim-SC_OLD-0568c76a8801408665730702c97717d3c05cfe4d.tar.xz | |
Use a thread abort safe version of OpenMetaverse.DoubleDictionary with the aim of avoiding OpenSimulator problems due to script thread aborts.
When an object is removed, its scripts are stopped and then the thread running them is aborted if stop takes too long.
However, it appears that aborting a thread at just the wrong moment when it is obtaining a ReaderWriterLockSlim lock can leave this lock in an inconsistent state.
One symptom of this is that mono leaps to 100% cpu and a vm thread dump reveals lots of threads waiting for a ReaderWriterLockSlim lock without any thread actually holding it.
This is probably the same problem as encountered originally in commit 12cebb12
This commit looks to plaster this problem by putting lock obtaining methods inside finally blocks which should be uninterruptible by thread aborts.
Diffstat (limited to 'OpenSim/Region/Framework/Scenes/SceneCommunicationService.cs')
0 files changed, 0 insertions, 0 deletions