At 15.15 -0600 0-08-30, Alastair Reid wrote:
>> How do you get the actual size of the
>> current stack in a stack check? What is rlimit_stack here, and how do you
>> get hold of it?
>
>It's easy enough to get the (approximate) address of the stack
>pointer: just take the address of a variable allocated in the current
>stack frame.  Then add (for downward growing stacks) a conservative
>estimate of the current stack size (e.g., 8k on entry to main) to give
>the start address of the stack.  Now subtract the maximum stack size
>and, hey presto, you have the address of the stack limit.

This might work well on older UNIX systems, but what happens under Mach,
which uses paging and virtual memory and stuff; perhaps the stack isn't in
contiguous memory (I don't really know these things). To be on the safe
side, one should check if the OS has a stack size function, and if not, one
can try your hack.

>> >   If it triggers, throw an exception that the programmer
>> >   can catch in the IO monad.  (See code for throwing pattern match
>> >   exceptions for comparision.)
>>
>> The problem is though that the situation is critical when the stack is low,
>> so having an exception might not make sense. But one could offer the
>> possibility of trying to reset the stack limit, and if that fails, the
>> ability to start a new program.
>
>So the (C) code that catches an exception (i.e., the setjmp) should
>check for stack overflow and, if that fails, rethrow the stack
>overflow exception (which makes the C stack smaller, of course).
>Eventually (in fact, rather quickly), you'll find an exception handler
>that is safely below the stack overflow limit.  (There is always one
>exception handler in place during evaluation and if there's not enough
>stack space for that, then Hugs just won't work at all.)

I think that the normal thing would be that the program already before
starting has a stack increment size. If the STACK_CHECK detect a low stack,
the first thing it should do is to try to increment the stack using the
stack increment variable. If that does not help, a stack overflow exception
is thrown. (If the variable is set to zero, the exception could be thrown
right away.)

>Of course, the programmer might have written an infinite loop using
>exception handling:
>
>  catch big (\ _ -> 1 + big)

One can never set guarantees against programmer follies...

>but we can already deal with infinite loops by hitting ctrl-C (or whatever).
>As long as that works (and I see no reason it shouldn't) we're cool.

Under UNIX it should work. Under cooperative multitasking (MacOS, Windows,
Palm), one will have to spray the code with interrupt checks.

  Hans Aberg



Reply via email to