[Lldb-commits] [PATCH] Add Read Thread to GDBRemoteCommunication.

[Ewan Crawford]

I looked into how GDB processes async packets with only one thread. Essentially GDB has a high level event loop which listens for events from multiple sources. Events are queued and only processed later by calling the appropriate handler, allowing the event loop to continue listening for more events. There is an event for async notification packets which is generated when the notify packet is received, but only responded later so that it doesn't interfere with regular synchronous communication.  The event itself is generated from either polling the serial connection or looking for a synchronous response after a send.

For our purposes polling isn't the best solution since we can spawn a thread from Communication easily. However delaying the notify processing does address a race condition I didn't previously cover.

(a)  ---> m
 (b) <--- %notify
 (c)  [broadcast notify packet received]
 (d)  ---> vStopped [broadcast is handled by listener in AysncThread before reply to (a) is received]
 (e)  <--- memory reply to (a), unexpected response to vStopped.

This patch fixes this by getting SendPacketAndWaitForResponse() to Hijack the notify broadcast, then rebroadcasting after the synchronous response has been seen. Avoiding interference with regular synchronous communication.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D10085

Files:
  source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D10085.27521.patch
Type: text/x-patch
Size: 12250 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150611/430afbc5/attachment.bin>