Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Fri, 9 Feb 2001 23:23:49 -0500 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: A process can't have more than 63 child processes. Message-ID: <20010209232349.A31414@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20010208090337 DOT A29571 AT redhat DOT com> <000401c0923b$add86660$1a01a8c0 AT ajasoft02> <20010209114233 DOT I18080 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <20010209114233.I18080@redhat.com>; from cgf@redhat.com on Fri, Feb 09, 2001 at 11:42:33AM -0500 On Fri, Feb 09, 2001 at 11:42:33AM -0500, Christopher Faylor wrote: >On Fri, Feb 09, 2001 at 02:57:37AM +0100, Espen Harlinn wrote: >>Another possible solution would be to create additional threads, >>and delegate the WaitForMultipleObjects, using 3 threads, one to >>manage the other two, would allow 124 children to be executed. > >I believe that I already mentioned this scenario yesterday. > >I'm not interested in doing this, but I would certainly wouldn't reject >a patch. FWIW, I've moved the number of supported children down to 63 and added an error return to fork for the failing condition. cgf