On Thu, Apr 10, 2008 at 2:53 AM, Philippe Gerum
<[EMAIL PROTECTED]> wrote:
>
> Robert McCullough wrote:
>  > Hi Gilles,
>  >
>  >   --> -----Original Message-----
>  >   --> From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED]
>  >   --> Sent: Wednesday, April 09, 2008 3:29 PM
>  >   --> To: [EMAIL PROTECTED]
>  >   --> Cc: [email protected]
>  >   --> Subject: Re: [Xenomai-help] mlockall questions
>  >   -->
>  >   --> Robert McCullough wrote:
>  >   -->  > Hi,
>  >   -->  >
>  >   -->  > I am converting part of a C++ application to real-time.
>  >   -->  >
>  >   -->  > I noticed that all the Xenomai examples call
>  >   -->  > mlockall(MCL_CURRENT|MCL_FUTURE) at the beginning of main before
>  >   --> creating
>  >   -->  > any real-time threads.
>  >   -->  > Is calling mlockall a requirement when using Xenomai?
>  >   -->
>  >   --> Yes it is.
>  >   -->
>  > [Robert McCullough]
>  > OK.
>  >   -->  >
>  >   -->  > I have added a couple of Xenomai tasks to my C++ app.
>  >   -->  > A) Without calling mlockall my application seems to run fine but I
>  >   --> noticed
>  >   -->  > in /proc/xenomai/stat that a few page faults occurred.
>  >   -->
>  >   --> Well normally your application should stop with a message telling you
>  >   --> that you have not call mlockall. Do you happen to install a handler
>  >   --> for
>  >   --> SIGXCPU ?
>  > [Robert McCullough]
>  > Yes.
>  >   -->
>  >   -->  > B) When calling mlockall at the beginning of my main() I do not 
> see
>  >   --> any page
>  >   -->  > faults but some of the C++ threads do not start.
>  >   -->  >
>  >   -->  > Why would mlockall cause some threads not to start?
>  >   -->
>  >   --> Well, you should check rt_task_create or pthread_create return
>  >   --> value. The usual error is that you run out of memory because of the
>  >   --> stack size problem explained in the TROUBLESHOOTING guide.
>  >   -->
>  >   --> --
>  >   -->
>  >   -->
>  >   -->                                             Gilles.
>  > [Robert McCullough]
>  > Thanks.
>  > Calling "ulimit -s 2048" before my application in my startup script seems 
> to
>  > work fine when I am running over nfs to the Denx ELDK with a bash shell.
>  > But my application needs to run from a CompactFlash card running BusyBox on
>  > a MPC5200 and BusyBox does not seem to support the "ulimit" command.
>  > Is there another way to set this stack limit size?
>  >
>
>  - Setting the stack size property into the attribute struct for each new 
> pthread
>  your application may create: pthread_attr_setstacksize(&thattr, stacksize);
>
>  - Or passing the right stack size value to any (non-POSIX) Xenomai API task
>  creation service, we do enforce it (e.g. rt_task_create(), taskInit(),
>  t_create()...).
>
>  - Or calling setrlimit(RLIMIT_STACK, ...) to set a global default value for 
> all
>  subsequent glibc-originated threads. This is what the ulimit command does, 
> actually.

The problem of pthread_attr_setstacksize (or of setting stack size in
one of the various thread creation services) is that it does not work
for the main thread stack. So, you have to use ulimit or to call
setrlimit before running your application, in order to set the main
thread stack size.

Now about the ulimit builtin in busybox: busybox ash shell supports ulimit.

-- 
 Gilles

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to