Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ptsfa!dual!forbrk!mats
From: mats@forbrk.UUCP (Mats Wichmann)
Newsgroups: comp.bugs.sys5
Subject: Re: Sys V handling of insufficient swap space.
Message-ID: <201@forbrk.UUCP>
Date: Sun, 8-Mar-87 13:30:33 EST
Article-I.D.: forbrk.201
Posted: Sun Mar  8 13:30:33 1987
Date-Received: Tue, 10-Mar-87 03:44:29 EST
References: <1035@wang7.UUCP> <1078@hoxna.UUCP> <444@vsedev.VSE.COM> <1083@hoxna.UUCP>
Reply-To: mats@forbrk.UUCP (Mats Wichmann)
Organization: Fortune Systems/Berkeley, Berkeley CA
Lines: 16
Keywords: swap crash

How is it relevant that moving the array into the 'data' segment causes
the kernel to be able to detect that the program is bigger than some
compiled-in limit on the size of an image (or its' data segment, anyway)?
That's not what the original question was.

It's a little bit tricky to decide how much stack space to make available
for automatic variables, especially large arrays, in a given system -
because *someone* will exceed whatever limit you set and find your
limit unreasonable. For example, lots of 68000 systems used to (maybe 
still do) settle on 32k simply because it lets you use short addressing 
for all "stack-relative" operations. In that case, it may have been more 
of a compiler-driven choice. If you don't set some sort of limit, you do 
get the chance for the sort of deadlock mentioned in the original
article.

Mats