On Thu, Mar 29, 2012 at 01:31:17PM -0430, Andres Perera wrote:
> On Thu, Mar 29, 2012 at 11:29 AM, Otto Moerbeek <o...@drijf.net> wrote:
> > On Thu, Mar 29, 2012 at 10:54:48AM -0430, Andres Perera wrote:
> >
> >> On Thu, Mar 29, 2012 at 10:38 AM, Paul de Weerd <we...@weirdnet.nl> wrote:
> >> > On Thu, Mar 29, 2012 at 10:24:27AM -0430, Andres Perera wrote:
> >> > | > Instead, you'll crank your file limits to... let me guess, unlimited?
> >> > | >
> >> > | > And when you hit the system-wide limit, then what happens?
> >> > | >
> >> > | > Then it is our systems problem, isn't it.
> >> > | >
> >> > |
> >> > | i am not sure if you're a suggesting that each program do getrlimit
> >> > | and acquire resources based on that, because it's a pita
> >> >
> >> > Gee whiz, writing programs is hard! B Let's go shopping!
> >> >
> >> > | what they could do is offer a reliable estimate (e.g. 5 open files per
> >> > | tab required)
> >> >
> >> > Or just try to open a file, *CHECK THE RETURNED ERROR CODE* and (if
> >> > any) *DEAL WITH IT*
> >>
> >> but we're only talking about one resource and one error condition
> >>
> >> write wrappers for open, malloc, etc
> >>
> >> avoiding errors regarding stack limits is not as easy
> >
> > There are very few programs that actually hit stack limits. MOst cases
> > it's unbounded recursion, signalling an error.
>
> doesn't change the fact that preempting it takes modifying your
> compiler's typical function prelude (and slowing down each call)
>
> additionally, anticipating FSIZE would greatly slow done each write
>
> so no, you can't just "be correct" all the time and pat your self on the back
>
> >
> >>
> >> obviously there's no reason for: a. every application replicating
> >> these wrappers (how many xmallocs have you seen, honest?) and b. the
> >> system not providing a consistent api
> >
> > Nah, you cannot create a apifor this stuff, proper error handling and
> > adaptation to recousrce limits is a program specfic thing.
>
> well, if including logic that gracefully handles the stack limit is
> not important on the basis of most application's needs, then i don't
> see how the reverse relation couldn't justify a library with xmalloc
> and similar. *most* applications that implement this function copy
> paste the same fatal version. see also `#define MIN/MAX`
You just seem to argue for the sake of it. Anyway....
A lot of programs have a *static* limit on stack depth, so those
programs do not have that problem.
For programs where the stack depth is a functon of the input (for e.g.
parser and expression evaluation), there are well known techniques to
control the maxium depth. Most of these programs actually have their
own parse stack management and do not use the function stack for
that.
In my experience, I only have seen programs hitting stacks limit when
the stack limit was very low, like 64k or so. Hitting the stack limit
is not a real world problem. Our default stack limit is 4M: big enough
for virtually any program, and small enough to catch unbounded
recursion before it will eat all vm.
Hitting mem or fd limit *is* as real world problem. Beacuse both
memory and fd usage can build up, even in a well written program. In
contrast to stack usage.
And just using xmalloc or similar for those cases is often not a
solution, epsecially not for daemon programs. Handling resource
exhaustion is a difficult problem that cannot be "solved" by just
quiting your program, even if a lot of program do so.
-Otto
