From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Gerum In-Reply-To: <4A0AC81A.7050000@domain.hid> References: <1242219577.26544.952.camel@domain.hid> <4A0AC81A.7050000@domain.hid> Content-Type: text/plain Date: Wed, 13 May 2009 15:30:56 +0200 Message-Id: <1242221456.26544.960.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [Xenomai-help] Periodic threads not scheduled anymore during debug session List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Steven Kauffmann , xenomai@xenomai.org 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. -- Philippe.