On Mon, 2010-12-27 at 17:50 +0100, Kolja Waschk wrote: > Hi, > > > The test code creates SCHED_OTHER threads. This is likely not what you > > wanted to do. > > It indeed doesn't describe my original problem, but while compacting the test > code, I found that it doesn't make a difference. The behaviour is the same > (or at least the symptoms are the same) .. > > 1. ... with the threads created with prio>0, EXPLICIT_SCHED and SCHED_FIFO > 2. ... with additionally the main thread being set up for SCHED_FIFO too
A possible explanation is that we know ptrace() is sending your app linux signals, particularly with legacy linuxthreads under the hood. Since your thread relaxes due to printf() as well, the combination of both events normally bumps the current thread out of real-time mode AND stops the RPI boost too, which may cause the next thread to preempt. What happens if you only log the debug info in some global array, and dump its contents after all threads are joined, instead of issuing printf() in the thread body? > > Kolja > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
