DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1FD733857C47
Date: Wed, 26 Aug 2020 19:57:24 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Limit for number of child processes
Message-ID: <20200826175724.GQ3272@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <000401d67ba0$8b1f33b0$a15d9b10$@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <000401d67ba0$8b1f33b0$a15d9b10$@gmail.com>
Precedence: list
Reply-To: cygwin@cygwin.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces@cygwin.com
Sender: "Cygwin" <cygwin-bounces@cygwin.com>

On Aug 26 14:00, Kristian Ivarsson via Cygwin wrote:
> Dear cygwin folks
> 
> It seems like there's a limit of the number of possible child processes
> defined to 256 with 'NPROCS' in //winsup/cygwin/child_info.h used in
> 'cprocs' in //winsup/cygwin/sigproc.cc
> 
> 256 is quite few possible children in an enterprise environment and perhaps
> the limit should be limited by the physical resources or possibly Windows ?

The info has to be kept available in the process itself so we need
this array of NPROCS * sizeof (pinfo).

Of course, there's no reason to use a static array, the code could just
as well use a dynamically allocated array or a linked list.  It's just
not the way it is right now and would need a patch or rewrite.

As for the static array, sizeof pinfo is 64, so the current size of
the array is just 16K.  We could easily bump it to 64K with NPROCS
raised to 1024 for the next Cygwin release, at least on 64 bit.
I don't think we should raise this limit for 32 bit Cygwin, which is
kind of EOL anyway, given the massive restrictions.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
--
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