Re: [PATCH 0/2] Better handling of slow remote transfers

[Gary Benson <gbenson@redhat.com>]

Sandra Loosemore wrote:
> On 08/17/2015 02:53 AM, Gary Benson wrote:
> > It seems to me that being able to interrupt file transfers is
> > polish.  With the warning patch alone, users will see the warning
> > and the hint about how to restore the previous default, which they
> > can apply and continue as before.  If they have to wait out a
> > transfer then it will presumably only be once.  I know some people
> > use GDB on systems with 5,000+ shared libraries, and others use
> > GDB on slow serial links, but I don't think anybody combines these
> > cases.
> 
> FYI, I am not debugging over a "slow serial link".  I've been
> testing this on an Altera 3c120 board (Nios II) with 10/100
> Ethernet; it NFS-mounts the sysroot under test and before now that
> has worked fine with no obvious responsiveness issues.
> 
> > So, would the warning+hint patch alone be enough?
> 
> Is it really user-friendly to make the user either wait 4 minutes
> of kill GDB through a separate terminal before they can act on the
> hint?

This user-friendliness argument is almost a straw man.  Is it
user-friendly to make the user wait 4 minutes before they can update
their .gdbinit and continue as before?  Probably not.  Is it
user-friendly to make the user set up NFS on the target or copy all
the files across (and keep them synchronized)?  Also probably not.
Is it user friendly to expect users who want GDB to locate binaries
for them to add "set sysroot target:" to their .gdbinit?  Also
probably not.  Is it user friendly to expect users who want to use
GDB across containers to add "set sysroot target:" to their .gdbinit?
Also probably not.  So lets leave user-friendliness to one side and
talk about what's actually happening.

For some reason, the Altera 3c120 board you are using is very much
slower to transfer files over RSP than it is over NFS.

For some reason, neither of the two QUIT patches I mailed work on your
setup with this Altera 3c120 board you are using even though they work
just fine on this x86_64 machine I am using.

Your PandaBoard takes 8 seconds.  That doesn't seem so bad to me.
If this Altera board is the only one with the massive slowdown then
I don't think we should delay 7.10 any further on this issue--and I
certainly don't think we should lose the functionality that the
default sysroot of "target:" brings.

Thanks,
Gary

-- 
http://gbenson.net/