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

[Gary Benson <gbenson@redhat.com>]

Pedro Alves wrote:
> On 08/12/2015 04:08 PM, Gary Benson wrote:
> > Pedro Alves wrote:
> > > On 08/12/2015 02:58 PM, Pedro Alves wrote:
> > > > GDB will usually cap the transfers to before they get to the
> > > > lower layers.  E.g., look for 4096 in memory_xfer_partial,
> > > > target_read_alloc_1 and target_fileio_read_alloc_1.
> > > >
> > > > As this request is coming from the BFD side, we should
> > > > probably make remote_hostio_pread also cap the size of the
> > > > vFile:pread request.  A reasonable number like a few KBs
> > > > should not introduce any noticeable slow down.
> > >
> > > But wait, I'm now confused -- isn't this a red herring?  Since
> > > gdbserver is already limiting transfers to PBUFSIZE, this change
> > > should have no practical effect, right?
> > >
> > > How can BFD's large remote_hostio_pread result in large
> > > vFile:pread: packet responses then?
> > 
> > I think gdbserver is returning multiple packets but something in
> > GDB (getpkt_or_notif_sane_1?) is concatenating them together
> > somehow.
> 
> No, getpkt_or_notif_sane_1 will return as soon as it has a single
> packet, which should then be bubbling up the layers and reaching
> gdb_bfd_iovec_fileio_pread.  Something else is going on.  Either the
> QUIT is being lost/eaten, or ... hmm ... maybe the SIGINT handler is
> set to remote.c:async_handle_remote_sigint when the ctrl-c is typed,
> which means the ctrl-c doesn't actually set_quit_flag()?

I've no idea.  Really I haven't.

I have to finish for the day now.  I'll be back in 16 hours.
Maybe somebody who'll benefit from interruptible remote transfers
could look into this while I'm away.  Sandra?  Pedro?  Doug?

Thanks,
Gary

-- 
http://gbenson.net/