Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Draft ambiguity
Message-ID: <3636@ut-sally.UUCP>
Date: Fri, 22-Nov-85 21:16:55 EST
Article-I.D.: ut-sally.3636
Posted: Fri Nov 22 21:16:55 1985
Date-Received: Sun, 24-Nov-85 05:33:22 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 25
Approved: jsq@ut-sally.UUCP

Date: Fri, 22 Nov 85 09:34:32 cst
From: ihnp4!uiucdcs!ccvaxa!preece@SEISMO.CSS.GOV (Scott Preece)

> From: athena!steved%tektronix.csnet@CSNET-RELAY.ARPA
> The limits file is not intended to represent necessarily the current
> limit.  For example, PROC_MAX tells an application programmer that he
> knows that there can be n processes existing simultaneously.  However,
> the o.s. implementer may have some dynamic allocation scheme where the
> actual limit varies with say system load.  The goal of the standard is
> to allow that kind of implementation.
----------
There are a lot of error definitions in the draft that specifically
say that specific, named system limits have been exceeded.  For
instance, the fork error code mention PROC_MAX and CHILD_MAX.
If the limit is, in fact, dynamic or otherwise differs from the
named constant, you are causing confusion...

[ Yes, it's hard to find non-confusing language to describe this.  -mod ]

-- 
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece

Volume-Number: Volume 3, Number 39