Mailing-List:	contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin-developers AT sources DOT redhat DOT com
Date:	Thu, 8 Feb 2001 09:03:37 -0500
From:	Christopher Faylor <cgf AT redhat DOT com>
To:	cygwin-developers AT cygwin DOT com
Subject:	Re: A process can't have more than 63 child processes.
Message-ID:	<20010208090337.A29571@redhat.com>
Reply-To:	cygwin-developers AT cygwin DOT com
Mail-Followup-To:	cygwin-developers AT cygwin DOT com
References:	<s1sofwd7dq0 DOT fsf AT jaist DOT ac DOT jp>
Mime-Version:	1.0
User-Agent:	Mutt/1.3.11i
In-Reply-To:	<s1sofwd7dq0.fsf@jaist.ac.jp>; from fujieda@jaist.ac.jp on Thu, Feb 08, 2001 at 05:58:47PM +0900

Yep.  This has been noted before.  The WaitForMultipleObjects
restriction makes it impractical to have more than 63 children.

I guess we should set PSIZE to 64.

cgf

On Thu, Feb 08, 2001 at 05:58:47PM +0900, Kazuhiro Fujieda wrote:
>I'm afraid the following includes only problem reports.
>
>A process in Cygwin seems able to have up to 1023 children 
>because of the following code of `subproc.cc' and `pinfo.h'.
>
>subproc.cc (proc_subproc)
>247:     case PROC_ADDCHILD:
>248:       if (nchildren >= PSIZE - 1)
>249:	system_printf ("nchildren too large %d", nchildren);
>250:       pchildren[nchildren] = vchild;
>pinfo.h
>21: #define PSIZE 1024
>
>But a process can't have more than 63 child process in practice,
>because WaitForMultipleObjects can't wait over 64 objects
>according to MSDN.
>
>subproc.cc (wait_subproc)
>1234:       DWORD rc = WaitForMultipleObjects (nchildren + 1, events, FALSE,
>1235: 					 proc_loop_wait);
>
>In addition, fork doesn't return any error when a process create
>too many children, because proc_subproc properly handle this
>error as quoted above. I expect fork returns -1 and set errno to
>EAGAIN.

- Raw text -