Re: [RFA] Fix gdbserver queued packet handling

[Pedro Alves <pedro@codesourcery.com>]

On Friday 30 April 2010 18:17:31, Doug Evans wrote:

> 2010-04-30  Doug Evans  <dje@google.com>
> 
> 	* server.h (queue_file_read_event): Declare.
> 	(reschedule_remote): Declare.
> 	* event-loop.c (queue_file_read_event): New function.
> 	* remote-utils.c (reschedule_remote): New function.
> 	(readchar_buf, readchar_bufcnt, readchar_bufp): New static globals,
> 	moved out of readchar.
> 	* server.c (handle_serial_event): Call reschedule_remote.

This looks good, thanks.  Please apply.

> @@ -3009,6 +3009,10 @@ handle_serial_event (int err, gdb_client
>       Important in the non-stop mode asynchronous protocol.  */
>    set_desired_inferior (1);
>  
> +  /* Give the packet reader a chance to schedule more work before
> +     we go to sleep.  */
> +  reschedule_remote ();
> +

This seems to break the abstraction a bit.  GDB attempts
a reschedule on every `readchar', and avoids unnecessary calls
into the event loop by maintaining a state machine, so
everything is nicelly hidden within the serial handling code.
But I'm fine with this simpler mechanism.  I can't think
of any reads from the socket outside of handle_serial_event;
we'd be still in trouble this way if there were.  In non-stop, we
push stop notifications to gdb when handling target events, but
asynchronous RSP notifications are a special kind of packet
that is never acked, even if no-ack is off, so not even those
cause reads that could cause data being pulled to the buffer.

-- 
Pedro Alves