I looked at this and I think it is probably ok. The reason we were doing this messing with SEH code was not to support SEH In the context of stackless, but to make sure that we were not accidentally trampling any higher SEH in place when doing task switching. As long as this patch does that, then we should be fine. We should probably make sure that the "stub" never has any SEH handlers to begin with, so that an exception in a fresh tasklet doesn't cause those to start to try to unwind the stack because it makes no sense.
I'll take another look and this and then get it committed when I find the time. Thanks! K From: [email protected] [mailto:[email protected]] On Behalf Of Gil Colgate Sent: 16. apríl 2012 18:33 To: The Stackless Python Mailing List Subject: Re: [Stackless] Patch to exception handler. Did this meet with anyone's approval? On Mon, Apr 9, 2012 at 11:43 AM, Gil Colgate <[email protected]<mailto:[email protected]>> wrote: Here is a fix for the exception handler, I included just the .patch. This corrects the problems with python having a different exception the environment when the item is called again. In the previous code, whenever a python tasklet was suspended the top of the exception chain was saved. This very well could be a pointer into code above the python stack into the main program. When the python tasklet is called again, it's stack is put back *in the same place*, but the environment above the stack *might be different*. This would cause the exception chain to screw up in the part where the exception chain points above the stack. This was the cause of the broken exception chain bug. If a tasklet has none of it's own exception chains, we will discover this by reading the exception list and seeing that the address is above the stack, so we don't need to save or restore it it. If, on the other hand, the tasklet has a chain we save it. When restoring it we look at the current chain and insert the chain from the restored stack into it at the appropriate spot, so that the tasklet's chain points correctly into it's parent's change. Stack slicing: Stackless in general has a problem with stack slicing. This code will work in when the stack is sliced (I tested it with 2K stack slices and try-catches everywhere) but certain exceptions that belonged to inactive stack slices will not be executed since they are not currently linked into the chain.
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
