Gilles Chanteperdrix wrote: > 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. >
Even if you don't have any shell supporting ulimit, you just need to create a small launcher that basically forks/setrlimit+execs your application. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
