ulimit (was: getty/login for callback)

[Robert C. White Jr.]

in article <1021 at quintus.UUCP>, ok at quintus.UUCP (Richard A. O'Keefe) says:
> 
> Agreed, that's a handy facility which several operating systems support.
> BUT you want to do that on a per-file basis.  If I want to write one 1M
> file and 16 4k files, I have to have ulimit high enough for the worst
> case, so I may end up writing 17Mb by mistake.  You could have a limit
> associated with a process which was inherited by each fd opened for
> output by that process, with the ability to set it down on each fd.

The problem with this is that the code in the debug version would be
substancially different than the eventual release material (changing
limits if any and whatnot).  I beleive that the general limit is a
better idea because it allows for *uniform* and *scaled* runaway
growth patterns to be more easily perceived.  By setting the limit
at a reasonably high value and providing this as a "hard failure"
point you can better trace your problem... e.g.

Were you to set a 1.3MB limit on your 1M file, and a 5K limit on your
4K files then if the runaway condition "peeked" one file first  (in say
a round robbin processing scheme, or dynamic schedule handeler) you would
be pointed at a spesific file.  This data would be congruent to the
generall threshold concept except in some of the more obscure finery.
That is to say, a general termination-condition falure might yeild =>
2MB & 16x8k files (by double processing) but if one of those files
were terminated at a 5k juncture and it were the first polled event or
something, you would be chasing after a singel file problem.  Similar
datum are avalable by observing 1x1MB 12x4K 3x1.6MB and 1x2MB file sets;
such datum being limited by individual thresholds.

The small limit for inital development; large limits for dynamic testing;
and instalation limits for final product -- type development paths
do tend to produce strong code and procedure.  Leastwise it never
did me any harm.

Rob.