On Tuesday 09 June 2009, Øyvind Harboe wrote: > On Tue, Jun 9, 2009 at 7:37 PM, David Brownell<davi...@pacbell.net> wrote: > > On Tuesday 09 June 2009, Ųyvind Harboe wrote: > >> - make all reset event scripts run with background > >> events disabled. > > > > Surprises me that's not already the case... > > > > Note that output of "poll" doesn't say whether the timer > > thing is active. So it's pretty much hidden. > > > > Also, that the documentation doesn't mention *why* this > > background activity might be desired. Is there a better > > reason than "that's how it's always been done"? > > An example of why this was done in the past is that when > you type "resume", you want to get a message when the > target halts. So when the command line is in idle, you poll.
Makes sense. > However, I've given some thought to when polling should > be active and perhaps we have gotten it wrong and > *no* polling should be done. > > Instead we could define that a telnet session that shows > a prompt is *NOT* idle, but rather that a telnet prompt waiting > for input is polling the *active* target. > > So during execution of a command or when the telnet > is closed and only gdb is running, there is no background > polling. That's what I would expect. Only poll if the event could happen, and there's a listener that cares about it. And the only event of interest seems to be transitioning from a "running" or "debug-running" state ... to something else. With the only listeners being the TCL shell, or in some cases GDB (when a breakpoint or watchpoint fires). > I'm not a great fan of numerous handlers that listens > for events(control inversion) and invokes fn's that somehow > have to figure out if it is time to do something or other... Sometimes async/event-driven code is required. I have a similar aversion to code that tries to model async realities in synchronous terms. ;) In this case there's true concurrency except when all the targets are halted. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
