bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Resource limitation causing erractic behaviour?


From: Paul Jarc
Subject: Re: Resource limitation causing erractic behaviour?
Date: Fri, 08 Mar 2002 22:04:21 -0500
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-redhat-linux-gnu)

"William L. Maltby" <address@hidden> wrote:
> Summary: Is it correct that I was exhausting resources, do you think?

I'd guess so, if the problem disappears on better-equipped machines.
Can you look at the memory usage, etc., at the moment of failure?

> Do you have any "practical" ones that might warn me when I'm getting
> too aggressive with my style for a particular machine config?

Not really.

>> Another option, if you script A sourcing script B sourcing script C,
>> etc., is to use iteration instead of recursion:
>
> Recursion? You mean like in C? I'm _not_ doing that I hope.

You are, sort of.  One script sourced with "." sources another with
".", which sources another (right?).  This is recursion with respect
to the "." command.  Thus a (potentially very deep) stack of entire
scripts has to be maintained.  But I don't mean to imply that you have
a script sourcing itself, or script A sourcing B sourcing A, etc.

> But the below is recursion, isn't it? Doesn't this also start making
> deep stacks, huge heaps, etc unless I take great care to unset no-
> longer-need variables?
...
>> set - initial-script ...
>> while [ "$#" != 0 ]; do
>>   script="$1"
>>   shift
>>   . "$script"
>> done

No deep stacks.  Variables do linger, but the scripts contents
themselves don't, which is the main point.

> Any nasty side-effects on a) chroot done by shell # 1 to start
> shells # 2 by the chroot ... -c "..." and the /bin/bash --login - c
> "..." at the end of shell 2 and 3?

I think I'd have to see the whole script system to say.

> At the start of each shell, the first thing is to load the _same_
> common routines.  I execute a couple of those functions, same ones
> next. Each reads a .cfg file that load appx 50 variables, but their
> short names (all 5 or fewer characters) and all but one have less
> that 12 characters in their values.

I don't think this would have a large impact.  Cascading sourcing
means the entire text of each script is held in memory while all the
scripts beneath it are executed, and I think that's the main problem.

> Does sourcing discard some kind of temporary environment also?

No.

You might consider using a different language with better memory
management, maybe Perl or Python.  The main advantage of shell
scripting is in the ease of calling external commands and redirecting
file descriptors.  But that can be made nearly as easy in other
languages with just a few well-designed utility functions.


paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]