[cdt-dev] Timeouts for GDB/MI commands (Was: [DSF] Making Sequence more

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Thursday, October 20, 2011 21:40:17 Pawel Piech wrote:
> > 2. While a general repository for outstanding RM's might be a good idea,
> > what would you say if we start small, and implement the solution that
> > would remember outstanding RequestMonitor instances for some limited
> > cases (for example, 'target *-remote' commands in DSF-GDB, and then
> > cancel those RequestMonitors after a timeout? This is somewhat
> > orthogonal from the initial goal of catching lost RMs, but seems
> > sufficiently related and immediately useful.
> 
> This is something that could be done at the service level, where these 
> commands are issued.  If we expect that the back-end may never complete 
> some commands then in those cases a timeout guard should even be 
> required.  For example, we queue commands with the command control, but 
> we count on the process monitor to notify us if the back end process 
> dies.  At that point we complete any outstanding command in queue with 
> an error.  So our process monitor is the guard.

We discussed this approach internally (turned out to be faster), and Mikhail
has proposed approach like this:

1. Add new interface:

    interface IMIControlTimeoutPolicy {
  
        void commandSend(CommandHandle);
        void commandDone(CommandHandle);

    }

2. Add new method AbstractMIControl.createTimeoutPolicy (returning null by default).
Adjust the code so that when this method returns non-null, the commandSend and commandDone
methods of the result are called by TxThread/RxThread as appropriate.

3. Make GDBControl.createTimeoutPolicy return a policy that sets a timer whenever a command
is sent, and if the command is not done within a timeout, just calls GDBControl.shutdown.

Does this seem reasonable, on a high level? We should be able to implement this fairly
quickly.

Thanks,

-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
+7 (812) 677-68-40