This patch captures and serializes all output being written by the
command line driver, including the lldb prompt being output by
editline, the asynchronous process output & error messages, and
asynchronous messages written by target stop-hooks.

As part of this it introduces a new Stream class,
StreamAsynchronousIO.  A StreamAsynchronousIO object is created with a
broadcaster, who will eventually broadcast the stream's data for a
listener to handle, and an event type indicating what type of event
the broadcaster will broadcast.  When the Write method is called on a
StreamAsynchronousIO object, the data is appended to an internal
string.  When the Flush method is called on a StreamAsynchronousIO
object, it broadcasts it's data string and clears the string.

Anything in lldb-core that needs to generate asynchronous output for
the end-user should use the StreamAsynchronousIO objects.

I have also added a new notification type for InputReaders, to let
them know that a asynchronous output has been written. This is to
allow the input readers to, for example, refresh their prompts and
lines, if desired.  I added the case statements to all the input
readers to catch this notification, but I haven't added any code for
handling them yet (except to the IOChannel input reader).



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130721 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/source/Interpreter/CommandInterpreter.cpp b/source/Interpreter/CommandInterpreter.cpp
index a36d9c2..16e5f3b 100644
--- a/source/Interpreter/CommandInterpreter.cpp
+++ b/source/Interpreter/CommandInterpreter.cpp
@@ -1226,7 +1226,10 @@
             out_file.Flush ();
         }
         break;
-
+        
+    case eInputReaderAsynchronousOutputWritten:
+        break;
+        
     case eInputReaderGotToken:
         if (bytes_len == 0)
         {
@@ -1642,6 +1645,12 @@
             }
         }
         
+        if (result.GetImmediateOutputStream())
+            result.GetImmediateOutputStream()->Flush();
+        
+        if (result.GetImmediateErrorStream())
+            result.GetImmediateErrorStream()->Flush();
+        
         // N.B. Can't depend on DidChangeProcessState, because the state coming into the command execution
         // could be running (for instance in Breakpoint Commands.
         // So we check the return value to see if it is has running in it.