Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Occasional 'job table full or recursion limit exceeded'
- X-seq: zsh-workers 17646
- From: Felix Rosencrantz <f_rosencrantz@xxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxx
- Subject: Re: Occasional 'job table full or recursion limit exceeded'
- Date: Wed, 11 Sep 2002 03:36:06 -0700 (PDT)
- In-reply-to: <1020909162233.ZM32158@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
--- Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author