From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4A0AC81A.7050000@domain.hid> Date: Wed, 13 May 2009 15:16:10 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <1242219577.26544.952.camel@domain.hid> In-Reply-To: <1242219577.26544.952.camel@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 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: Philippe Gerum Cc: Steven Kauffmann , xenomai@xenomai.org 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? -- Gilles.