Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Freezing all Xenomai timers while just a single RT application is under
>> ptrace control can be helpful in certain debugging scenarios, but it can
>> as well be harmful when other parts of the systems have to continue to work.
>> I brought this concern up back in 2006, and I originally thought we may
>> address this by freezing per process. But this is far too complex for a
>> simple problem like this: Just make the whole thing configurable, and
>> keep it off by default so that -ideally- only users who are aware of the
>> side effects will arm it.
> No, it's the other way around, you know when you don't want a timer to
> be blocked because it serves some purpose that goes beyond the
> application duty, like keeping a RTnet connection alive through which
> you happen to debug; on the other hand, all other timers relate to the
> logic the application implements, so you most often want them to track
> the debugging state so that they don't mess up behind you back when the
> debugger halts the application. Blocking timers during ptracing should
> be on by default, no need to break a known behaviour Xenomai had for
> ages for rare cases when some of them are also used to maintain some
> external activity alive. This is the exception, and as such, those
> timers should be marked as non-blockable in the code that defines them;
> a global knob may then switch them to blockable if needed.

You focus on single application, or single function per system.
Moreover, following this logic, you would have to suppress all
interrupts as well while ptracing some app.

> An intermediate approach would be to force the threads ptimer and rtimer
> as blockable ones, and use a global flag to switch the rest as
> non-blockable, albeit this may cause non-related watchdogs to keep
> triggering, which most of the time could be a real pain in the neck when
> debugging.

That' sounds better, specifically switching to a XNTIMER_BLCK logic.
What about freezing the ptimer and rtimers of all xnthreads in ptraced
processes? That shouldn't require us to track additional information in
xntimer_t about its owner.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to