Re: RFA: auto-retry TCP connections for "target remote"

[Sandra Loosemore <sandra@codesourcery.com>]

Joel Brobecker wrote:

> I'm just wondering why you chose to implement the idea inside ser-tcp?

In large part because I'm not very familiar with GDB internals, and this is 
where what I was trying to do was failing.  :-P

> Especially since the name of the associated settings "remote auto-retry"
> and "remote connect-timeout" does not suggest that it is specific to
> a particular transport protocol.

That's where it was suggested to me that I put it.  I'm actually pretty confused 
by the organization of the remote configuration commands; some of them are "set 
remote foo", while others are "set remotebar", and there's also "set serial" 
documented as being for "serial/parallel port configuration".  If there's a plan 
to all this, I don't know what it is.  :-(

> I wonder if it wouldn't be both simpler and more general to do everything
> at the remote.c level.Something like replacing the call to serial_open ()
> by a loop that calls serial_open a few times until we either succeed or
> exceed the number of retries. What do others think? 
> 
>> +set remote auto-retry (on|off)
>> +show remote auto-retry
> 
> Rather than having an on-off setting, can we have a setting that
> allows us to configure the maximum number of retries. If set to zero,
> then it's equivalent to "auto-retry off".

I'm willing to try to re-work the patch if there's agreement this would be a 
better approach.  My main concern is that there are some kinds of connection 
failures that really ought to be treated as immediately and permanently fatal; 
for instance, if the process launched by "target remote |" fails to start 
(because the command line was given incorrectly, etc), or the named serial 
device doesn't exist or has permission problems.  Maybe serial_open ought to 
explicitly set a status code to indicate a retry-able failure, with the default 
that failures are fatal?

-Sandra