From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 86A3D384607A for ; Thu, 27 Aug 2020 12:17:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 86A3D384607A Received: by mail-lj1-x234.google.com with SMTP id r13so2736329ljm.0 for ; Thu, 27 Aug 2020 05:17:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Zt58VZUjI3UinUj/R6tmLIz9dUsVRAVqJtVPxd9JG2k=; b=JSXxoG1seWmKNzKP37CWqJxAO9V6K7SEXeRsTwWQMo28PT1lMNytis3W9aHiYJ+BIb A9TXqK0Fh320oKl134E+EcU95ea858BbGu8xoHrAkMAsc+8beZyE5TdzYs7GQf3AIbW2 j6Ysxl4xElUkcJNyh5flHNz5mfJ58bVUWT+BNwAlkfqekqalghlTNR3Hme1XFTJis3Du 6L3aw7eCPFEOHgBx0iZFtD2tUaywWMMhVM/jgCnF1VCZGdkKN5gKB4LxE/R/vhGKPicj is/r/5XJ3gCWs5ygXZu3Rno5TeK5VP7EusnSDz3CtzgX70Q4iHXYQ78ltnNF5f9agjs7 K/4g== X-Gm-Message-State: AOAM530/6INzzNO7+3Tz2gmeWeIXg97Q7jIZ1qkCR3YtfiUKz2sunqti +8KLYQOImaHvn7HuAefxWucrR3/UOsI= X-Google-Smtp-Source: ABdhPJx+vYmamA7qUm9x5LYt2tNStVnErubX859VolTWJhj+MyXlzihSgKWozdfF5QWkF6oYVpwnTw== X-Received: by 2002:a2e:9f4e:: with SMTP id v14mr10138405ljk.72.1598530663813; Thu, 27 Aug 2020 05:17:43 -0700 (PDT) Received: from JOKK (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id q5sm472853lfn.92.2020.08.27.05.17.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2020 05:17:43 -0700 (PDT) From: To: References: <000401d67ba0$8b1f33b0$a15d9b10$@gmail.com> <20200826175724.GQ3272@calimero.vinschen.de> In-Reply-To: <20200826175724.GQ3272@calimero.vinschen.de> Subject: Sv: Limit for number of child processes Date: Thu, 27 Aug 2020 14:17:42 +0200 Message-ID: <000701d67c6c$10bcf720$3236e560$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI7mQ+hPIKf2raSwP+uxe6Dh/MnugIebBIUqHCwKVA= Content-Language: en-gb X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 12:17:47 -0000 Hi Corinna > > 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. I don't know the exact purpose of this and how the cprocs is used, but I'd prefer something totally dynamic 7 days out of 7 or otherwise another limit would just bite you in the ass some other day instead ;-) A linked list could be used if you wanna optimize (dynamic) memory usage but an (amortized) array would probably provide faster linear search but I guess simplicity of the code and external functionality is the most important demands for this choice I'm looking forward for a future release where there's no children limit Keep up the good work Best regards, Kristian > 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