Alan Burlison wrote: > Jan Dubois wrote: > >>> that in this case it can be entirely avoided, and if it can't be >>> entirely avoided I'd prefer 100% breakage instead of random nasty >>> surprises. Even if the various fixes *appear* to work I'd not be >>> prepared to trust them myself anyway, I'd recompile. >> >> >> I think Nick's new hashing code is binary compatible with both 5.8.0 and >> 5.8.1. In this case I don't see a reason for breaking it in the future. >> Just handwaving "it only *appears* to work" seems a little insulting to >> Nick's hard work, unless you can explain where you expect it to fail. > > > I think Nick and Stas and all the other people who have weighed in have > done an excellent job, however mod_perl makes me nervous at the best of > times, and this makes me doubly nervous. It looks to be very hard to > get it right - for example Stas mentioned that the hashing stuff has to > be working before a perl interpreter is even created for mod_perl - bu > then again I'm just a natural pessimist ;-) I also wonder if we will > hit any snags in things like Tk and DBI. I hope and pray it works, but > we (Solaris) have a ~3 year release cycle, customers don't like to patch > or upgrade. Thankfully we have a bit of time before the go/no go for > Solaris. Alan, your worries have been accounted for. This is precisely the reason I wanted to have a test that mounts an attack on stashes. So we now test that mod_perl 2.0 works just fine if and when such attack happens. Notice that I talk only about stashes, since that's where the black magic overlaps with mod_perl functionality. All other hashes in the "user" space should have no effect on mod_perl. It just proves again how important is to write tests before you start solving a problem. We saw mod_perl 2.0 goes broken immediately after plan C was implemented. Though once Nick changed the threshold for rehashing from 4 to 14 the breakage has disappeared, because the normal tests didn't happen to trigger it (that's where your worry kicks in). Now that we have a specific test that mounts the attack and it verifies that the attack was successful (to prevent cases of future changes in the rehashing algorithm) we are covered 100%. If we didn't have this test you indeed would have seen random failures reported by users some time later. I doubt that plan C affects any other projects, that don't mess with hashing internals like mod_perl does, any different that they get affected by changes in 5.8.1. So if Tk and DBI did fine with 5.8.1 they will do just as fine with 5.8.2 (assuming of course that they don't mimic mod_perl ;) __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.comThread Previous | Thread Next