Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!amdahl!ames!ucbcad!ucbvax!decvax!decwrl!labrea!rocky!ali
From: ali@rocky.STANFORD.EDU (Ali Ozer)
Newsgroups: comp.sys.amiga
Subject: Re: Dynamic Stack Allocation
Message-ID: <701@rocky.STANFORD.EDU>
Date: Mon, 26-Oct-87 10:09:30 EST
Article-I.D.: rocky.701
Posted: Mon Oct 26 10:09:30 1987
Date-Received: Thu, 29-Oct-87 00:03:12 EST
References: <4585@zen.berkeley.edu> <21440@ucbvax.BERKELEY.EDU>
Reply-To: ali@rocky.UUCP (Ali Ozer)
Organization: Stanford University Computer Science Department
Lines: 26

In article <21440@ucbvax.BERKELEY.EDU> Bryce Nesbitt writes:
>In article <4585@zen.berkeley.edu> Jonathan Dubman writes:
>>I have a speedy maze program ...
>>it needs a large stack.  Maximum resolution requires about 150K of
>>stack space. (Massive recursion.)   ...
>> "Reset your stack size and run me again.".
>
>Anyone starting it from Workbench will only get that message if they played
>with the icon.  Anyone starting from the CLI when an icon exists can probably
>figure out how to type "stack 150000".

You might also try launching a subprocess with the correct
stack size. In fact, you might be able to determine the necessary stack
size from the resolution and launch the main recursize code with the 
stack size set "just right." If you can prevent the recursive section of the
code from doing any DOS stuff (like file I/O), then you can make it
a task, and include it as a function in your program. Then, to launch
it you would use CreateTask(), which takes a stack size and a
starting address as an argument. If it somehow fails, it could send back
a message or a signal to the parent task. This structure could also make
it possible to abort the computations more gracefully, perhaps, if you
had the parent waiting on both the child's and Intuition's signals.
If the child did no memory allocations of its own, then the parent could
kill it will a single RemTask(), >poof<.

Ali Ozer, ali@rocky.stanford.edu