Shouldn't there be implementations of InterruptRead in this patch?

It seems like you are saying InterruptRead will consume all available stdout, 
then return Interrupted, which is a little odd for an interrupt.  But I don't 
know what InterruptRead actually does...

Jim

> On Mar 11, 2015, at 4:13 AM, Pavel Labath <[email protected]> wrote:
> 
> Hi clayborg, jingham,
> 
> There was a race condition regarding the output of the inferior process. The 
> reading of the
> output is performed on a separate thread, and there was no guarantee that the 
> output will get
> eventually consumed. Because of that, it was happening that calling 
> Process::GetSTDOUT was not
> returning anything even though the process was terminated and would 
> definitely not produce any
> further output. This was usually happening only under very heavy system load, 
> but it can be
> reproduced by placing an usleep in the stdio thread 
> (Process::STDIOReadThreadBytesReceived).
> 
> This patch addresses this by adding synchronization capabilities to the 
> Communication thread.
> After calling Communication::SynchronizeWithReadThread one can be sure that 
> all pending input has
> been processed by the read thread. This function is then called after every 
> public event which
> stops the process to obtain the entire process output.
> 
> http://reviews.llvm.org/D8246
> 
> Files:
>  include/lldb/Core/Communication.h
>  include/lldb/Core/Connection.h
>  include/lldb/Host/posix/ConnectionFileDescriptorPosix.h
>  include/lldb/Host/windows/ConnectionGenericFileWindows.h
>  source/Core/Communication.cpp
>  source/Target/Process.cpp
>  test/python_api/process/io/TestProcessIO.py
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> <D8246.21685.patch>


_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits

Reply via email to