guy@auspex.auspex.com (Guy Harris) (03/20/90)
>(This is all the more disgusting because the problem that is most >likely to be to blame was understood years ago, and Geoff's paper >"A Partial Tour Through the UNIX Shell" at San Diego Usenix explained >it and how to fix it.) Well, it depends on which problem you're thinking of. The SunOS 3.2 Bourne shell was scoured for the "catch SIGSEGV and grow the 'stack'" hack. (Actually, the BRL Bourne shell - based, like the SunOS 3.x one, on the S5R2 Bourne shell - was the one that was scoured, and the changes were later applied to the 3.x one, but I digress....) Unfortunately, not all of the problems were caught (no, not all of the places where you have to check use "pushstak()", and we didn't rewhack the handling of the "stack" as much as you did). Some are still present in the 4.0 shell, but I think are fixed in the 4.1 shell. BTW, comments on a couple of statements in the paper: 1) "The Ninth Edition (and presumably System V Release 2) shell used some of the directory(3) routines from the C library..." Nope. The S5R2 shell couldn't use the directory routines from the C library since they weren't in the S5R2 C library. 2) "The performance impact [of checking manually rather than having the MMU do it] has not been measured, but appears to be insignificant." At one point, I compiled two versions of the shell, identical except that one did the checks and one depended on the "SIGSEGV hack", on a 3B2/400 running S5R3 (it happened to be the nearest handy system that 1) had an OS that could conveniently compile an S5-based shell like the SunOS 3.x one and 2) made the "SIGSEGV hack" work) and tried doing echo `cat *.c` in the hopes it'd really stress the code where the checks appeared. The performance impact was, in fact, insignificant, at least for that test. I'm curious what the performance impact was on the original PDP-11(s) on which the work was done, given that John Mashey has claimed, as I remember, that Bourne put the SIGSEGV hack in at his urging in order to speed up the shell.
mash@mips.COM (John Mashey) (03/22/90)
In article <3054@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >The SunOS 3.2 Bourne shell was scoured for the "catch SIGSEGV and grow >the 'stack'" hack. (Actually, the BRL Bourne shell - based, like the >SunOS 3.x one, on the S5R2 Bourne shell - was the one that was scoured, >and the changes were later applied to the 3.x one, but I digress....) > The performance impact was, in fact, insignificant, at least > for that test. > I'm curious what the performance impact was on the original > PDP-11(s) on which the work was done, given that John Mashey > has claimed, as I remember, that Bourne put the SIGSEGV hack > in at his urging in order to speed up the shell. Beats me. Just to make sure this statement is clarified: a) NEVER, EVER, did I urge this particular thing upon srb. b) However, I almost certainly caused it, because at the time, I was telling Steve we'd never switch because: 1) His shell used noticably more time than the PWB shell. 2) At the time [mid-76], we were driving 11/45s ruthlessly, (and slightly later, putting 45 users on an 11/70), and re-orging every file system every weekend, and watching the accounting files for people in need of tuning,.. and we couldn't buy machines fast enough. 3) Hence, a slower shell would be over our dead bodies.... c) At which point, Steve went into an orgy of tuning... d) I never heard how much this particular part of the tuning was worth. Note that you would see it a lot more in the case where you are continually allocating/reallocating memory (and thus not taking SIGSEGVs). Just to show there's justice in the world, I paid for my (indirect) sin of item b) above when I left BTL and went to work at Convergent on 68010s... -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253, or 408-524-7015 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086