> > Something else I should mention: The clipping code performs no memory
> > allocations, so drawing keeps off the heap. When an obscuring window
> > splits a rectangular blit into two rectangles, the routine recurses for
> > each, so the complexity of the visible area goes on the stack. Now, how
> > much stack space does the kernel have? :)
>
> Kernel stack is TINY. On iX86 it's only 7KiB or so. And when you'll overflow
> if you'll corrupt you system badly, BTW.
Doh! Ok, I need to learn more. I take it this means recursive in kernel
is totally a bad idea then?
I can either try to deal with this dynamically by checking how much stack
is left, or just completely changing strategies to put all the dynamic
stuff in a growable heap chunk. What do you recommend?
Doh doh doh...
BTW, what are symptoms of stack overflow? Any pointers to required
reading here? Thanks.
- Ben.
-------------------------------------------------------------------
Ben Williamson benw@pobox.com http://www.pobox.com/~benw/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/