Stack handling and exiting a comp via next() - ATTN Jon this needs your input
Dave Rolsky <[email protected]> Sat, 14 Oct 2006 15:51:21 -0500 (CDT)
| Newsgroups | gmane.comp.web.mason.devel |
|---|---|
| Message-ID | <[email protected]> |
Jon, in the 1.3x series, you changed the way the request object manages the stack so we no longer use Perl's push and pop to add/remove items from the stack. Instead, we manually manipulate track the current stack depth. AFAICT, this was done to work around stack corruption when a component exits via next(). Unfortunately, the side effect was to introduce a pretty nasty leak, because what ended up happening is that stack frames were never being removed from the stack, we just changed changed the value of the "top of the stack" variable internally. In 1.34, I introduced a change to pop the stack so that the frame (and objects it references) actually get destroyed when the user expects. I consider this a pretty serious bug, more serious than stack corruption because of a bogus next. Unfortunately, it seems like this popping introduced more bugs. The existing code is really complicated, because it is in effect a re-implementation of what Perl does internally for array handling. When I revert the code back to just using Perl's push and pop, as we did through 1.28, the tests pass except for the "exit via next" test. Personally, I think that this is fine. The problem with next or last is unfortunate, but Perl at least spits out a warning when you do it, so the user gets some clue as to what's going on. It's not intractable to find such bugs, and IMO it's not worth impossible gyrations to work around this, especially when fundamentally the problem is with Perl itself. Using next or last outside of loops should just be a no-op. Anyway, I'd like to go ahead and revert the code that tries to manually manage the stack and just use push and pop, like we used to, and then release 1.3401 (or 1.35). The real rub in all this is that I haven't been able to come up with a nice isolated test of what I'm seeing in my app with 1.34 (a screwed up stack where one of the frames is undef, for example). I'll keep trying to come up with such a test. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/ ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642