29 May
2005
29 May
'05
8:49 p.m.
On Sun, May 29, 2005 at 04:33:34PM +0200, Christian
Schoenebeck wrote:
alternatively, allocate a huge stack based object early in the
thread's life (preferably before RT-ness matters). if mlockall() has
been called, any pages allocated to the stack will remain locked in
physical RAM. problem solved.
--p
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 AB
I
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.