DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60MEpD0G2148628
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 60MEpD0G2148628
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=T9OyryVv
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1E0414BA2E3C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1769093472;
	bh=8mIWdc0s7DviAQu+zQvLKf+UIfs1eljJ+D59MehmOX0=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=T9OyryVvjQFRkTNyQzilpz9Ohb0Q0ayjz0wXWPLP5AOFdFWMlJYGqYp/nsvK5eMdf
	 sl+Xl8JyupfYOT+Y/BVUdMp8+kq9G61IVunXozOAjRcHNVkmnNpWI+Iq8BuE22QNcg
	 qLwvZoMMvTgC20EG2UeDCtTmestafXNUbFzRk3W8=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ACC2F4BBCDDD
Date: Thu, 22 Jan 2026 15:50:22 +0100
To: cygwin AT cygwin DOT com
Subject: Re: Fork bomb question about Cygwin
Message-ID: <aXI5LisBF92YQAXy@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <MN2PR09MB492382DA1F993B72742E1A98A596A AT MN2PR09MB4923 DOT namprd09 DOT prod DOT outlook DOT com>
 <aXH2YPIcgWqd8zyX AT calimero DOT vinschen DOT de>
 <aXI3osLanp-VA5qV AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <aXI3osLanp-VA5qV@calimero.vinschen.de>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

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