Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.unix.wizards
Subject: Re: anne.jones dumps core
Message-ID: <37246@mips.mips.COM>
Date: 22 Mar 90 03:33:40 GMT
References: <1990Mar15.185725.27695@ccu.umanitoba.ca> <1990Mar16.191820.9978@utzoo.uucp> <3054@auspex.auspex.com>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 43

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