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 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) Content-Type: text/plain; charset=US-ASCII From: Kazuhiro Fujieda Date: 08 Feb 2001 17:58:47 +0900 Message-ID: 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 | HOKURIKU School of Information Science o_/ 1990 Japan Advanced Institute of Science and Technology