[IronPython] Thread local storage in IronPython 2.6

Dino Viehland dinov at microsoft.com
Mon Oct 5 23:56:12 CEST 2009


Michael wrote:
> >> At the top level you could put all the cleanup code inside a finally
> >> block so that thread aborts can't interrupt it. :-)
> >>
> >
> > Somehow I guess I'd quickly get a bug report that Ctrl-C no longer works
> > too :)  But there's a kernel of a good idea there - it's certainly
> > easier than using Constrained Execution Regions which was my longer
> > term plan (and also has trouble w/ partial trust unlike a normal
> > try/finally).
> >
> 
> Well, it would only postpone the ctrl-c whilst the cleanup code ran, right?

Oh, I misread that...  I skipped over "cleanup" in "cleanup code" :) I was 
thinking of putting all of the code in a finally for some reason :)

But the cleanup code is already in a finally.  But sometimes it's structured as:

stack = PushFrame(...);
try {
} finally {
	stack.RemoveAt(stack.Count - 1);
}

In this case there's a small window of opportunity where the abort could happen
after the push frame and before we enter the try block.  

Elsewhere it's actually structured like this:

try {
	stack = PushFrame(...);
} finally {
	stack.RemoveAt(stack.Count - 1);
}

Here there's the possibility of aborting before the push frame but after we 
enter the try which leads to popping too many frames.  Worse still both of
these have the possibility in aborting during the list.Add() call which may
corrupt the underlying list.

So really we need something like:

bool pushedFrame = false;
try {
	try {
	} finally {
		stack = PushFrame(...);
		pushedFrame = true;
	}
} finally {
	if (pushedFrame) {
		stack.RemoveAt(stack.Count - 1);
	}
}

But this code would be broken in the face of Rude Thread Aborts (luckily they're
not much of a concern for us).  Fixing this one is where the CERs come into 
play.









More information about the Ironpython-users mailing list