From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 621 invoked from network); 11 Sep 2002 10:36:20 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 11 Sep 2002 10:36:20 -0000 Received: (qmail 10389 invoked by alias); 11 Sep 2002 10:36:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 17646 Received: (qmail 10373 invoked from network); 11 Sep 2002 10:36:08 -0000 Message-ID: <20020911103606.7681.qmail@web10412.mail.yahoo.com> Date: Wed, 11 Sep 2002 03:36:06 -0700 (PDT) From: Felix Rosencrantz Subject: Re: Occasional 'job table full or recursion limit exceeded' To: Bart Schaefer , zsh-workers@sunsite.dk In-Reply-To: <1020909162233.ZM32158@candle.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Bart Schaefer wrote: > I'm not really sure what to say, because the message you quoted doesn't > have anything to do with the thread you're replying to. (The excerpt > above refers to the number of background jobs spawned by my "zargs" > function, not to the value of MAXJOBS in the C code.) I'm a wee bit red faced... :) > Part of the problem is that the value of MAXJOBS was established when > each job table entry represented a real unix process. Now that we make > job table entries for internal shell control structures, we need more > table space. It still shouldn't need to grow without bound (though I > believe we have other anti-infinite recursion mechanisms in place now). I didn't really appreciate that MAXJOBS is sort of taking on the role of a control structures stack. In which case, a dynamic solution seems reasonable. Currently I'm building with MAXJOBS doubled, figuring that should cover it for me. Though I suspect most users have prebuilt versions of zsh, and so might hit this problem. -FR. __________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute