> -----Ursprüngliche Nachricht----- > Von: xenomai-core-boun...@gna.org [mailto:xenomai-core-boun...@gna.org] > Im Auftrag von Philippe Gerum > Gesendet: Mittwoch, 13. Mai 2009 15:42 > An: Gilles Chanteperdrix > Cc: Steven Kauffmann; xenomai-core@gna.org > Betreff: Re: [Xenomai-core] [Xenomai-help] Periodic threads not > scheduled anymore during debug session > > On Wed, 2009-05-13 at 15:34 +0200, Gilles Chanteperdrix wrote: > > Philippe Gerum wrote: > > > On Wed, 2009-05-13 at 15:16 +0200, Gilles Chanteperdrix wrote: > > >> Philippe Gerum wrote: > > >>> On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote: > > >>>> Hi all, > > >>>> > > >>>> If I connect a debugger to my application, other Xenomai > periodic > > >>>> threads (threads that not belong to the current process I'm > debugging > > >>>> ) are not scheduled anymore. Attached you can find a simple > example > > >>>> that reproduces the problem. I run the program 2 times in a > different > > >>>> terminal and connected a debugger to one of them. When a > breakpoint is > > >>>> reached both programs stops their execution but I would expect > that > > >>>> only the program that I'm debugging should stop and not both. > > >>>> > > >>>> $ cat /proc/xenomai/sched > > >>>> > > >>>> CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT > NAME > > >>>> 0 0 -1 0 0 master R > ROOT > > >>>> 0 5469 0 1000000001 331274938 master D > > >>>> 0 5471 0 1000000001 0 master XT > > >>>> > > >>>> This looks normal one thread is stopped ( thread that reaches > the > > >>>> breakpoint ) and the other one is delayed because it's a > periodic > > >>>> thread. Every time I call this command the timeout of the > delayed > > >>>> thread changes so it looks like this thread is still running but > in > > >>>> reality it is not. > > >>> This behavior is wanted (I mean, the implementation does freeze > all > > >>> thread timers when a break state is reached on purpose), so that > you > > >>> don't get tons of overruns once the debuggee is restarted. > > >>> > > >>> However, I'm now wondering if we should not be a bit smarter than > this, > > >>> and narrow the scope of such action. We do have the mechanisms to > do so, > > >>> it is just a matter of using them. > > >> Do we? I mean, are we able to know which process a timer belongs > to? > > >> > > > > > > We could tag the per-thread timers (rtimer, ptimer) using their > status > > > field, and move back to the owner thread using container_of() when > > > applicable. > > > > What if an application uses rt_alarm_create/rt_alarm_wait? > > Those do not create per-thread timers. We just want to follow a bit > more > the principle of least surprise, and prevent common programming > patterns > to be affected by this feature. > > For the rest, we would have to reverse the current logic and tag > blockable timers instead of non-blockable one. The shadow code would > then have to tag the ptimer/rtimer of the ptraced thread as blockable, > leaving all other timers as unblockable by default. > > >
Do you know when this will be implemented? We have a kernel watchdog service running (Xenomai task) which always restarts our system while debugging (because the watchdog is not triggered anymore). I assume that this problem is related to the one above. Thanks Thomas -------------------------------------------------------- manroland AG Vorsitzender des Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 USt-Ident-Nr. DE 250200933 _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core