On Fri, 2010-08-20 at 16:08 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Fri, 2010-08-20 at 15:58 +0200, Jan Kiszka wrote: > >> Philippe Gerum wrote: > >>>> However, terminating gdb and restarting app outside gdb > >>>> does make RTDM task resume execution. Before, the driver had to be > >>>> reloaded. > >>>> > >>>> So gdb appears to be causing timer to block even if no breakpoint is set, > >>>> probably signals? > >>>> > >>> There is no reason for that. Sending "continue" to gdb is expected to > >>> unblock the timers, until the code is single-stepped again (e.g. after > >>> ^C or any breakpoint). > >> gdb silently intercepts a traced program for various reasons, e.g. > >> thread creation or library loading. Even if no user breakpoint is set, > >> the program may briefly be stopped nevertheless. If that happens > >> frequently enough, and every stop can add latencies to running timers... > > > > We are talking about permanent freeze of timers, not transient (at least > > this is what I got from the ongoing discussion). > > Yes, but what would happen if the interruption rate is higher than the > timer delay? Wouldn't we effectively end up with a permanent freeze?
If the _signal_ rate is higher than the timer delay and continuous, then either the guy sending ^C via the keyboard should go easier on the coffee, or gdb has a severe problem and should be fixed, whichever comes first. > > Jan > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
