I won't try to "point" to documentation....
Each co-routine should have it's own separate stack. Best practices with
stack management today have a sufficiently large stack that grows and then
terminates in unmapped memory. If it is attempted to grow the stack too
much, then the program gets a memory exception (SIGSEGV on systems that use
it). Think about a recursive routine with relatively large local data
structures (stack-based). Such a routine could overwrite any amount of
stack, finish, and then return with no errors. The current PicoLisp
implementation sounds like, then, when a co-routine switch occurs, the
switched to routine could find it's stack corrupted.
And certainly operating system events could overwrite things deeper on the
stack during a context switch.

Rand


On Mon, May 20, 2013 at 6:43 PM, Alexander Burger <a...@software-lab.de>wrote:

> Hi all,
>
> since nearly three years PicoLisp supports coroutines (64-bit version).
> Now suddenly it occurred to me that the way I implemented them might be
> illegal.
>
> The problem is how individual stacks for the coroutines are allocated. I
> do this by reserving space on the stack (by decrementing the stack
> pointer) upon starting a new coroutine. Execution of that coroutine may
> be suspended (with 'yield', so that execution continues in the main
> program or some other coroutine), to be resumed later.
>
> Switching between individual (co)routines is done by moving the stack
> pointer up and down between the corresponding stack frames. Everything
> seems to work fine - though I haven't used coroutines in serious
> projects yet.
>
>
> Now I remember to have read that (in POSIX?) no valid data should be
> stored *below* the current position of the stack pointer. Is that really
> the case? I can't find any conclusive information about that.
>
> This switching between stack frames, as described above, of course
> leaves temporarily suspended stack frames *below* the stack pointer,
> while it points into a higher frame. Does this mean that the operating
> system might dispose or overwrite them? For example, when paging is
> required?
>
> Interrupts are probably not a problem, as they push their contexts on
> the system stack.
>
> Some sources say that even GCC stores (small amounts of) data below the
> stack pointer, while others (possibly some ABIs from Intel) say this is
> an absolute no-no.
>
> Can anybody point to a definite answer?
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Reply via email to