Altering the stack size for a Process

[Karlos]

Does anybody know if it is possible, in an OS legal way, to change the stack size for an already running Process?

I've looked at exec/SwapStackStruct(struct StackSwapStruct*), which states that the existing stack bounds and usp are swapped with the ones in the structure, allowing you to restore it later.

What I want to be able to do, is to allocate an area of memory for the new stack, clone the existing stack area and then swap it in for the new one, the net result simply being that the stack has "grown" (and naturally lives at a different address) but otherwise contains all the same data it did before the swap, leaving the Task none the wiser.

I can see a lot of problems with this if it isn't done carefully and several questions spring to mind. First of all, if all you are doing is replacing the stack area (with no desire to restore it later with a repeated call to SwapStackStruct()), is it legal to release the memory? How is it allocated in the first place (which method) to ensure your replacement allocation would be correctly freed by the system?

Anybody know of any robust existing examples of this kind of thing?

[Piru]

No

You can only use StackSwap(), and you MUST keep the previous stack alive aswell, as there might be live pointers pointing to data inside it. You MUST have matching StackSwap that restores the original stack once you're done with the part that uses the swapped stack (at least if your task/process is ever going to exit that is).

[bigdan]

Drop an eye on "stackattack" asm source ? You could perhaps use that sort of trick ??

http://aminet.net/package/util/boot/StackAttack2

[Piru]

[EDIT]

StackAttack2 doesn't alter stacksize of a already running task/process.

[/EDIT]

[Karlos]

Damn, I thought as much, to be honest.

This is a possible problem for one of my classes. It used to be the case that you could alter the stack size for a Thread which was not presently spawned and it would take effect on the next call to start() whereupon a new Process was always created. When the call to run() was completed by the Process, it would clean itself up and exit. The next call to start would basically spawn an entirely new Process. You were never able to alter the stack once it was underway until it completed its call to run(), unless you like eating ThreadStateViolation exceptions.

The new version of the simply "parks" the Process once it has completed the call to run() by waiting for a signal to be issued by the next call to start(). It only truly terminates when the Thread's destructor is invoked. This is obviously a bit more resource efficient than the old version.

I suppose the only way to support the old way of setting the stack "between jobs" would be to let the Process finalize itself if setStackSize() is called before the next call to start() and spawn a new one.