develooper Front page | perl.perl5.porters | Postings from November 2003

Re: 5.8.2 and 5.8.n binary compatibility

Thread Previous | Thread Next
Stas Bekman
November 3, 2003 13:37
Re: 5.8.2 and 5.8.n binary compatibility
Message ID:
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     mod_perl Guide --->

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About