Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpfcso!hpfelg!koren From: koren@hpfelg.HP.COM (Steve Koren) Newsgroups: comp.sys.amiga.tech Subject: Re: A REAL fork() function (was Re: SKsh weirdness) Message-ID: <13920050@hpfelg.HP.COM> Date: 27 Feb 90 15:10:38 GMT References: Organization: HP Elec. Design Div. -FtCollins Lines: 29 > Steve> Also, try giving it boatloads of stack. > I hate this approach. Stack space can eat resources FAST. Be > dynamic, dude. Put *pointers* on your stack, and AllocMem. Much > nicer. Less likely to crash, too... SKsh already does dynamically allocate everything of any significant size (such as tree parse nodes, etc), and passes only a few pointers around between functions. However, recursion can become quite deep, especially in the case of recursively called aliases or shell functions. Some functions declare quite a few automatic variables, and it is not practical to allocate 4-byte variables dynamically; this would kill the performance. I do suspect that SKsh will run with less stack than I recommend. However, there is one point which is a little unclear to me. In AmigaDos, when you run another program (*not* in the background) from yours, the second program runs using the same process as the parent. Does this mean that it uses the same stack space, as well? I'm not sure. I can't find that documented anywhere, so I always recommend more stack than should be necessary. Feel free to try less; if it works for you, great. - steve PS - I did some emperical tests, and Lattice's malloc() is significantly faster than AllocMem() (in addition to being standard). It only matters if you do alot of dynamic allocation, which SKsh does.