ncreed@ndsuvax.UUCP (Walter Reed) (01/14/88)
In article <126@forty2.UUCP> claudio@forty2.UUCP (Claudio Nieder) writes: >In article <22330@ucbvax.BERKELEY.EDU> bryce@hoser (Bryce Nesbitt) writes: >> The icon that started you tool decides the stack size. If the >> stack field is blank, then the default of ~4000 bytes is used. The >> size is recorded in the normal task structures. >I suggest the following improvment for 1.3: >Instead of takeing the stack size from the icon that was double-clicked, the >largest stacksize of all icons should be taken. > claudio That would be a waste of memory. What if the largest stack space of all the icons is 100K? How about looking at the process structure at the stacksize field? A program could check this, and if it is too small it could give the user a message to increase the stack size and restart the application. Is this possible or am I wrong? (I was looking in dosextens.h) -- Walter Reed UUCP : uunet!ndsuvax!ncreed Internet : ncreed%NDSUVAX.BITNET@CUNYVM.CUNY.EDU Ph 701-235-0774 Bitnet : ncreed@ndsuvax OR NU105451@NDSUVM1 -------------------
bryce@hoser.berkeley.edu (Bryce Nesbitt) (01/21/88)
In article <617@ndsuvax.UUCP> ncreed@ndsuvax.UUCP (Walter Reed) writes: >In article <126@forty2.UUCP> claudio@forty2.UUCP (Claudio Nieder) writes: >>In article <22330@ucbvax.BERKELEY.EDU> bryce@hoser (Bryce Nesbitt) writes: >>> >> >How about looking at the process structure at the stacksize >field? A program could check this, and if it is too small it could give >the user a message to increase the stack size and restart the application. >Is this possible or am I wrong? (I was looking in dosextens.h) #define FLAME_ON! Look out folks, I'm about to sound like a grouch... this posting symbolizes exactly what is wrong with comp.sys.amiga. Mr Reed, the first posting YOU QUOTED was dedicated ENTIRELEY to explaining EXACTLY HOW TO CHECK THE STACK SIZE. You ask "Is this possible or am I wrong?" If you has bothered to read the article you quoted before posting this speculative garbage you would have known that it is not only posssible, but how to do it! Think before you post. Please! #undef FLAME_ON! BTW: I thought before I sent this, and decided it was a bad idea. So much for a role-model :-). |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci") (") U "As an engineer, I only set the value of a product... not the cost." -Bryce Nesbitt
4526P@NAVPGS.BITNET ("LT Scott A. Norton, USN") (01/21/88)
In <617@ndsuvax.UUCP> Walter Reed: > >In article <126@forty2.UUCP> claudio@forty2.UUCP (Claudio Nieder) writes: >>In article <22330@ucbvax.BERKELEY.EDU> bryce@hoser (Bryce Nesbitt) writes: >>> The icon that started you tool decides the stack size. If the >>> stack field is blank, then the default of ~4000 bytes is used. The >>> size is recorded in the normal task structures. >>I suggest the following improvment for 1.3: >>Instead of takeing the stack size from the icon that was double-clicked, the >>largest stacksize of all icons should be taken. >That would be a waste of memory. What if the largest stack space of all the >icons is 100K? How about looking at the process structure at the stacksize >field? A program could check this, and if it is too small it could give >the user a message to increase the stack size and restart the application. The way to play it almost safe is to use the largest stack size listed on all the icons. However, that is probably wasteful of memory and won't work in all cases. We have to remember that extended selection and then double clicking a tool is in a way going against the default. Normally, you double click the project. The default tool fires up, and in this case, it is easy to know what stack size is needed. It is also appropriate for this information to be attached to the tool. But if you are altering the default by selecting a project and feeding it to some other tool, the assumptions made about the stack space are invalidated. An illustrative example. You have an IFF picture, with the default tool ":showILBM". Since its only a single picture, without a complex structure, you know how much stack space showILBM should need, and you set this to, say, 4000 bytes. But now, you click on the picture, and then double click on the "Big City Desktop Publishing Plus!" icon, intending to feed the picture into your SIG's newsletter. BCDP+! takes a pile of stack space, so the 4000 bytes from the project icon are not appropriate, either. I'm afraid I have no good solution. I can come up with situations where the project's complexity determines the stack space needed, or the tool's does, or some in-between situation. There are even times when neither the tool's default stack or the project's are enough, when you cross a complex project with a simple default tool into a complex project that usually takes simple tools. I am working on a stack extension set of routines that work with the Manx compiler's stack checking code. Unfortunately, these routines must be compiled into the program, the program must be compiled with Aztec C with stack checking enabled, and I make use of specific details about how the program maintains its stack, so it may break with new releases of the compiler. Plus, it can't correct all stack overflows, only those that occur on JSR - RTS pairs. But I'll post it after I test it some more. Right now, it works on my own code, but I don't know how much stack space Amiga library calls can use, so I don't know how much Headroom to leave on the stack. LT Scott A. Norton, USN Naval Postgraduate School Monterey, CA 93943-5018 4526P@NavPGS.BITNET 4526p@NPS.ARPA