SAS Stack setting?
18 messages in this thread
Got a guestion for any of you SAS C Guru's … I just picked up V6.0 today
and I was trying to do some work with background task. I thought that
setting the option "long __stacksize = xxxx;" would allow me to set the
stack that my task would be running at vice what the CLI etc.. that it was
executed from. What is the real beef with this? I set the value to 8k and
stack my CLI stack to 20k … and when I ran the program it had a 20k
stack! Is there a way to compile/link somehow so I can set my stack size
without a doubt. I am running to problems writing doors for various BBS
programs that require rather large stacks. I dont want a program of mine
that only uses about 200 or so bytes to be ran with a 40k + stack! Its a
waste of memory, and when you are running 12+ lines each memory waste adds
up REAL fast.
I would appreciate any help or if you have a code example to show me some
other way to do the same thing … that would be nice.
I think you misunderstand a little how the CLI works…
What normally happens, in the absence of setting __stack or anything
like that, is that each program run in the CLI inherits the CLI's
stack. You can set the size of the CLI's stack with the STACK
command.
If you set __stack, we will guarantee you a stack AT LEAST that
large. If the CLI's stack is large enough, we will use it; otherwise,
we allocate a new stack and use that instead.
If we were to always allocate you a 8k stack because you set __stack
to 8k, we would be wasting the 20k CLI stack that is already allocated.
There is no benefit to allocating the smaller stack.
To try out the option, set your CLI stack to 4k instead of 20k. Your
program will end up with an 8k stack even though the CLI has only 4k.
–Doug
The problem is that stack that the process that spawns my program is
already running with a stack of at least 40k. I have NO CONTROL over the
stack befre my program is launched. The blasted thing is huge! Why can't
I do something to make the stack size that my program uses smaller? Take a
10 line BBS with a stack of 40K on each line … if everyone online uses
one of my programs at the same time, thats 400,000 bytes in stack space
alone. I dont need to hog that much memory when I am using less than
10,000 bytes for all of them put together. I think I might be stuck with
getting the author of the BBS software to embed something in his program if
he is using SAS so everyone and their brother doesn't have to deal with the
memory hog from *&^%
Do you understand my gripe?
The basic problem is that there is no way to free up the stack which has
been allocated by the CLI to run your program. There is another option to
consider – CBACK which will cause your program to be run as a separate task
(automatically detached from the main CLI) and as a side effect allows you
to set exactly what the stack size will be.
Ok, I dont know if I am being stupid or not … but I tried the CBACK link
option already and when I even ran the sample program that came with the
compiler … according to Xoper the stack was STILL the same size as the
CLI that it was launced from. I run with about a 45K stack so I dont have
to worry about changing the stack back and forth for the BBS program when I
am cranking and testing code. I may be using all the wrong compiler and
linker options. Can you tell me which ones that I MUST have set in order
for that option to work … I will also go and snag the options to that
cback.c example program. For now I have the program compiled and written
to be resident. That I believe will be my best option for some of my
monster sized multi-line games.
When you ran the program, was the CLI freed up? How did you declare the
stack size? The CBack code does a call to CreateProc to set up a stack
based on the value in the stack size variable (unless this has changed in
6.0 and Doug will have to help you there).
This is the sequence of events. From startup … in the user-startup file
I set my stack to 45,000 off the bat. What I did again tonight to make
sure that I was not dorking anything up was (NOTE: I have V6.0 and I got
the patches for V6.1 from here and installed them) I looked within the
readme file and the ".c" modules for both back and schelp. I setup the
compiler/linker options according to the instructions in there … I
compiled the code etc.. and when I ran the program I looked with Xoper and
I saw that the program had a 45K stack. I compiled schelp with the options
specified there and set my stack to 4k. In this case the program did the
proper thing since "__stack" was set to 8k … the task had an 8k stack.
When I ran "back" I was able to close the parent CLI with NO problems at
all and Xoper still showed the program to have a 45K stack (That wasn't
gonna change anyways).
As for declaring the stack size for the program I left the sample source
code stock with the "long __stack = 4000;" in it and like I said before my
original stack was set to 45k using the "stack" command in the startup.
For your info … my system is an early version A500 with no enhanced chip
set. I have one of the first CSA 68020/68881 accelerators with a Xetec
hard disk interface and 5 megs total RAM. I do have the 2.04 ROM
installed.
Granted my system acts a little strange from time to time and makes me want
to think that Rod Sterling designed it vice Jay Miner but it works like all
other Amigas. Can you guys check out this problem … either I am dorked
or the compiler isn't doing what its supposed to be doing. Either way I
would appreciate finding the answer.
OK, I've just tried it here. I entered the following C source file:
#include <proto/dos.h>
long __stack = 1024;
char *__procname = "test of cback";
void main(void)
{
BPTR fh;
char c;
if(fh=Open("CON:0/0/100/100/foo/close", MODE_NEWFILE))
{
Read(fh, &c, 1);
Close(fh);
}
}
I then compiled the above program with SC X.C LINK STARTUP=CBACK.
I ran it and looked with SLIST, and the reported stack size was 1024 bytes,
as expected.
One word of warning, however: use the cback.o from version 6.0, not the one
from version 6.1. There is a minor bug in the 6.1 version that may or may
not show up on your system. You can retrieve the 6.0 version of cback.o by
inserting disk #2 from your 6.0 distribution and copying the file
"SASC_6.0_Disk_2:libraries/lib/cback.o" to your sc:lib directory.
–Doug
I will give it a shot with the 6.0 version of cback.o. I do believe thats
the version that I gave it a try with first. I will check again to make
sure and if it doesn't work this time I will send you a copy of the program
that I am trying to do it with and all of my conditions etc..
No, this hasn't changed.
How are you invoking the program? Are you using CreateProc yourself from
within the BBS program, or invoking it from the CLI directly? Or some other
method?
–Doug
That response should have went to me I guess. What I believe that the BBS
program is doing is basically a "run xxx" etc.. I will ask the author to
make sure. Its hard to tell since he has ARexx, C, DOS and someothere
things that can be launced by his code. But however the board is doing it
…. when I was playing with that code example "back.c" and executing it
from CLI I was getting the same response as I was with my doors for the
BBS.
Hmmm… If he's using Execute("run xxx"… or System("run xxx"…
perhaps he could try
Execute("stack 4000\nrun xxx",…
or the equivalent System() call. What Execute() and System() and their
variants do is effectively create a Shell that takes your string as
input. If you give it a newline in there, it'll behave just as if it
had read a newline in the Shell window; it will execute the command
read so far, then come back for more. In your case, it'll set the
stack size down, then invoke your program.
–Doug
I am getting really weirded out. I screen captured that code that you left
me in a previous message and I compiled it using the cback.o module from my
V6.0 disk. It did the same thing to me!! This program you said you used
SLIST or something like that … is that something that you guys have at
SAS for your own use or is it PD etc..? I have been using Xoper, because
thats about all I have for a universal check it all out, and it shows that
the program was using a 45k stack. I also closed down the CLI I ran it
from and everything was OK with the program etc.. it did make itself a
background task and all of that. I also executed the program from
workbench and then brought up a CLI and checked it out with Xoper … it
showed the program had a 4K stack now. I will be Easyplexing you that
program that you provided in that one message. Its compiled with V6.1
patch installed on my system and using the cback.o file from the disks.
What system are you trying all of your stuff out on? Is there any chance
that maybe something is strange in my ROM release? I dont know what to
tell you. If there is another stack listing program that you believe that
I should be using please tell me. It could be that there is a problem with
what Xoper is seeing … I just dont know. I haven't gotten a response
from the author of that BBS software. I left him a message earlier today
and I hope to get back with you on how he launches the programs.
One thing I will say about SAS .. I do like it! Never thought I would look
at workbench again but with all the neato stuff thats in there what the
heck.
Well off to Easyplex …
Great news!!! I am not crazy and you guys are right!! … looks like the
problem was Xoper itself. I am using an old version and I thougt
everything was still ok with it etc.. All of this code not working stuff on
my machine but just fine on yours was really bugging me bad. I knew that
something strange was missing from the big picture. When you mentioned
that you were using some program SLIST etc.. to list the stack usage I
decided that it was time to get a second opinion on my end. I downloaded
ARTM from here and it shows that the stack indeed was 1024 for your sample
program and the 4k stack etc.. that was in the "back.c" example provided on
the disk.
Wow .. its great to have your sanity back 🙂 I think I will play around
with my updated tool and see about the other code that I have been working
on for the BBS software support. I hope to find many suprises … well
thanks for the input … appreciate the support.
Interesting, it looks like Xoper is looking at a piece of information that
is not correctly set by CBack. Just from a quick thought, I know exactly
what is wrong. XOper is looking at either the cli_DefaultStack field
(which is certainly going to be 45K as you asked it to be – it is copied
from the parent CLI structure) OR it is looking at the pr_StackSize field
which may not be set correctly by CreateProc/CBack. I would be willing to
believe that it is the former.
Excellent, glad to hear that it's resolved.
I'll investigate XOper's strange number; it probably means that something
isn't set up correctly in the new cback process. I doubt if it will affect
the process itself other than to "lie" to programs like XOper, but I'll look
into it anyway.
–Doug
The stack size used in a CLI is the choice of the user. If the user wants to
waste 400k on stack size, that's his lookout.
However, you said that "the process" that spawns your program is running with
a 40K stack. If the process is another program, that program can control how
much stack you get using tags.
As to your comment about telling the BBS author to do something special if
running from SAS/C-compiled code, I don't believe we do anything differently
from other C compiler systems; indeed, some don't offer the ability to
specify a MINIMUM stack size either. The ability to specify a MAXIMUM stack
size has to my knowledge never been requested by another user, so I think
it's understandable that we don't offer it.
Finally, please try to be rational when discussing issues like this. I'm
perfectly willing to help you with your problem if I can, but I'm somewhat
put off by the angry tone of your postings.
–Doug
I dont know where I displayed an angry tone with my posting … got me on
that one. I just stated things in a cut and dry manner and I believe I
tried to convey the info … and if you thinking I was slamming SAS …
that was not the case. <enough on that issue>
I will try to pry the info out of the author of the BBS software I am
writing for and see just how he starts up other programs from his.