> For Vincent: > > My attached Scope::Upper WIP fix addresses two basic changes. First, that > context pushes don't push the old PL_savestack_ix onto the scope stack > any more, but instead store it as blk_oldsaveix. So saved savestack > indexes need adjusting in the context stack as well as the scope stack. > Second, pushing a context now usually involves pushing *nothing* on the > savestack (not even a SAVETMPS), so you can get a whole series of context > stack frames that all share the same blk_oldsaveix. So it makes it > difficult to trigger a call to leave_scope() and thus to su_pop() at the > right time. > > My solution to this was, when adjusting the chain of saved > PL_savestack_ix's, rather than adjusting each by the fixed size/offset, > adjust each so it is greater than the previous, so that leave_scope() > is always triggered when needed, and use extra padding if necessary. > Convert origin into an array of structs holding the original ix and the > offset. > When su_pop is called, rather than doing depth--, it assumes multiple > scopes may have been popped in one go (for example dounwind() will call > LEAVE_SCOPE() for every context popped, but not for any intervening > ENTERs). So instead it looks at the current value of PL_savestack_ix, > which points to the destructor currently being processed, then pops back > entries in origin until it finds one where origin[depth].ix + > origin[depth].offset < PL_savestack_ix. > Thanks for having looked into this. What you describe looks very much like a previous iteration of the implementation of Scope::Upper : it did seem more natural to flush all the empty save stack frames at once when the destructor fired instead of bumping all the save stack markers preemptively. However, it turned out that this approach did not work correctly when exceptions were thrown between the 'localize' call and the targeted scope end, as unwind() could then decide that there was no need to process the save stack. Things might have changed enough since then that this technique works now though, so it might be a good starting point, but I'm unable to check it in depth now or in the near future. VincentThread Previous | Thread Next