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
To:	cygwin-developers AT cygwin DOT com
Subject:	A process can't have more than 63 child processes.
Mime-Version:	1.0 (generated by tm-edit 7.106)
From:	Kazuhiro Fujieda <fujieda AT jaist DOT ac DOT jp>
Date:	08 Feb 2001 17:58:47 +0900
Message-ID:	<s1sofwd7dq0.fsf@jaist.ac.jp>
Lines:	29
X-Mailer:	Gnus v5.3/Emacs 19.34

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.
____
  | AIST      Kazuhiro Fujieda <fujieda AT jaist DOT ac DOT jp>
  | HOKURIKU  School of Information Science
o_/ 1990      Japan Advanced Institute of Science and Technology

- Raw text -