On Sun, May 29, 2005 at 04:33:34PM +0200, Christian Schoenebeck wrote:
But whatabout the stack? Even if you try to use the
heap for local variables
as well, you (usually) won't be able to prevent usage of the stack due to ABI
definitions; e.g. on most platforms function arguments will be delivered
through the stack. So what can you do to prevent physical pages to be
allocated for the stack at RT critical time? Because this would lead to the
same problems as calling malloc(), new and co.
True, arguments (and local variables) live on the stack, but normally
they should not take too much space. The thing to avoid is functions
that have large local arrays or objects, and this is almost always
possible.
If the above claim is true, then we could simply
increase the stack for a
short time at the beginning of a RT application, e.g. by calling alloca()
(maybe not good - dangerous and not portable) or by defining a big array on
the stack in a helper function and/or by making that helper function recurse
to a certain level to solve the danger of the stack.
Yes this should sove the problem if it exists. But I don't remember ever
having seen it in real life. Anyway, in typical DSP code, if you ensure
that signal buffers and the like are never created on the stack, I don't
think there is real problem.
--
FA