From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 24018 invoked from network); 20 Nov 1997 15:48:55 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 20 Nov 1997 15:48:55 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.8.5/8.8.5) id KAA28558;
	Thu, 20 Nov 1997 10:32:13 -0500 (EST)
Resent-Date: Thu, 20 Nov 1997 10:32:13 -0500 (EST)
From: Anthony Heading <aheading@jpmorgan.com>
Message-Id: <199711201518.PAA23534@gmp-etpres1.uk.jpmorgan.com>
Subject: Re: Bizarre Solaris problem
To: pws@ifh.de (Peter Stephenson)
Date: Thu, 20 Nov 1997 15:18:42 +0000 (GMT)
Cc: zsh-workers@math.gatech.edu
In-Reply-To: <199711141415.PAA22498@hydra.ifh.de> from Peter Stephenson at "Nov 14, 97 03:15:05 pm"
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"AbxfX3.0.9-6.yV5Tq"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3627
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

Peter wrote:
> Anthony Heading wrote:
> > Haha!  A quick update in case anyone is thinking about this.
> > 
> > The problem I've just tracked down to process limits.  csh is
> > initialising with the maxmimum number of file descriptors set to 64
> > (indeed the value of OPEN_MAX and supposedly the maximum limit
> > therefore for RLIMIT_NOFILE).
> > 
> > getrlimit(), however,  believes that the maximum number of file
> > descriptors is 1024, and zsh is bumping the limit up to that value.
> > This appears to confuse the 4.1.3 gethostbyname().
> 
> We saw this business apropos of something else a while ago.  OPEN_MAX
> is actually not the maximum limit, since it's run-time configurable
> under Solaris 2.  So presumably the difference that's causing the OS bug
> to show up is because csh is too old-fashioned to care.  Unless there's
> some reason for not following getrlimit() if all those descriptors aren't
> needed.

Not sure.

For my particular problem, Sun have been good enough to acknowledge this
as a bug in 2.5.1, and tell me it's fixed in the 2.6 Sun4 libraries.
(Exactly why one fixes the libraries, rather than have the kernel cap
the process limits to SunOS4 maxima when executing those binaries I
don't quite understand, but nevermind...)

Unless I've got this wrong (and I've got a cold at the moment so the
powers of analysis are somewhat below peak), zsh is displaying a
certain amount of youthful exuberance in widening the process limits
out to their hard stops.  No other shells appear to do this, instead
happily inheriting and reflecting the soft limits from their parents.

Now this is a matter of little practical import, mostly because few
people ever worry about these limits, and an extra line or lack of
it in .zshenv is not a big deal.  But after some thought, the
semantics seem undesirable:

 - it destroys information for little gain;
 - it's different from everyone else;
 - it potentially prevents implementation optimizations.

I know very little about POSIX and Unix standards and stuff, but if the
concept of hard and soft process limits are defined there, I'd doubt
that a shell is mandated to throw away the soft ones.

A