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.

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.

> Gilles, you recently stumbled over such a side effect and introduced
> XNTIMER_NOBLCK (for customized timer instrumentations as far as I
> understood this). Do you think we still need that knob when we have
> CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE?
> 
> Jan
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@gna.org
> https://mail.gna.org/listinfo/xenomai-core


-- 
Philippe.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to