zsh-workers
 help / color / mirror / code / Atom feed
From: Anthony Heading <aheading@jpmorgan.com>
To: pws@ifh.de (Peter Stephenson)
Cc: zsh-workers@math.gatech.edu
Subject: Re: Bizarre Solaris problem
Date: Thu, 20 Nov 1997 15:18:42 +0000 (GMT)	[thread overview]
Message-ID: <199711201518.PAA23534@gmp-etpres1.uk.jpmorgan.com> (raw)
In-Reply-To: <199711141415.PAA22498@hydra.ifh.de> from Peter Stephenson at "Nov 14, 97 03:15:05 pm"

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


      reply	other threads:[~1997-11-20 15:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-11-12 13:22 Anthony Heading
1997-11-12 17:45 ` Bart Schaefer
1997-11-13 17:17   ` Anthony Heading
1997-11-13 18:55     ` Richard Coleman
1997-11-14 14:15     ` Peter Stephenson
1997-11-20 15:18       ` Anthony Heading [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199711201518.PAA23534@gmp-etpres1.uk.jpmorgan.com \
    --to=aheading@jpmorgan.com \
    --cc=pws@ifh.de \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).