On Thu, Apr 10, 2008 at 4:36 PM, Philippe Gerum <[EMAIL PROTECTED]> wrote: > > 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.
Errr... but you need to call setrlimit before fork, otherwise it is too late... -- Gilles _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
