On Jan 22 15:43, Corinna Vinschen via Cygwin wrote: > Unfortunately there's a tricky difference between POSIX soft limits and > the way Windows job limits work. > > - Soft rlimits can be changed by any process, up or down, as long as the > new limit doesn't exceed the hard limit. A child process inherits the > limits, but it can change (raise!) them right away, only limited by > the hard limit. > > - Job limits on Windows can be changed by the process, but the limits > are accumulated if jobs are nested. The lowest limit wins. > > If a child process inherited a job limit, it can't raise the limit, > unless it knows the name of the job object *and* has the right to set > limits on this object. The problem here is, the current job the > process is running in, does not necessarily contain the information > about the real limit. This information may be in a job object higher > up in the job hirarchy. Unfortunately QueryInformationJobObject only > returns limits defined in this very job, not limits defined higher up. > And there's no way to fetch info about parent job objects, unless you > know their names or still have open handles on them. > > All in all, that means, the current implementation of > setrlimit(RLIMIT_AS) is not quite correct. The job object is inherited > by children, but then, if the child defines a new limit, it just creates > a nested job with this limit inside the already existing job. So the new > limit is ignored if the parent (or grandparent, or ...) job defines a > lower limit. > > Unfortunately the child can't just breakaway from a job. Only the parent > can do this for a child at CreateProcess() time. So we can't just > breakaway at setrlimit time and create a new, independent job object. > > The bottom line is, if we want to do this right, we have to redesign > the entire setrlimit thingy: > > - always allow BREAKAWAY_FROM_JOB > - always start the child with BREAKAWAY_FROM_JOB > - always create a new job object in the child after fork/exec implementing > the soft limits inherited from the parent > - in setrlimit: always just change the current job object
But then again, if we do it like this, per-process limits work as desired, but limits like RLIMIT_NPROC would not work. Did I say something about a tricky difference...? Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
