Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Wed, 11 Jul 2001 18:51:51 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: 1.3.2 : Fork + Sleep = problem Message-ID: <20010711185151.D29127@cygbert.vinschen.de> Mail-Followup-To: cygwin AT cygwin DOT com References: <3B4C1BF7 DOT 1807A0C7 AT aspen DOT mine DOT nu> <20010711131906 DOT K8578 AT cygbert DOT vinschen DOT de> <20010711 DOT 080113 DOT 96771529 DOT Takaaki DOT Ota AT am DOT sony DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010711.080113.96771529.Takaaki.Ota@am.sony.com>; from Takaaki.Ota@am.sony.com on Wed, Jul 11, 2001 at 08:01:13AM -0700 On Wed, Jul 11, 2001 at 08:01:13AM -0700, Tak Ota wrote: > On Wed, 11 Jul 2001 13:19:06 +0200, Corinna Vinschen wrote: > > > Since you only fork() but never wait(), your children processes > > become zombies. The zombie list per process is fixed to ... 64 entries. > > Then why doesn't fork() start returning -1 when the number of zombie > reaches maximum count? And why does sleep get affected by this? Since that's the flaw in Cygwin I mentioned. The effect to sleep() was basically due to writing over an array boundary which has reproducably hit another signal related variable. Unfortunately you'll have to wait for 1.3.3 or take a developers snapshot to get the fixed behaviour. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/