[Lldb-commits] [PATCH] Extend PipePosix with support for named pipes/timeout-based IO and integrate it with GDBRemoteCommunication / lldb-gdbserver.

[Zachary Turner]

================
Comment at: include/lldb/Host/PipeBase.h:32
@@ -30,1 +31,3 @@
+    Error OpenAsWriter(llvm::StringRef name, bool child_process_inherit);
+    virtual Error OpenAsWriterWithTimeout(llvm::StringRef name, bool child_process_inherit, const std::chrono::microseconds &timeout) = 0;
 
----------------
ovyalov wrote:
> zturner wrote:
> > This probably needs to go away now too.
> We need this method on POSIX systems since attempt to open a writer in non-blocking mode fails with ENXIO if corresponding reader side hasn't opened yet. So, timeout allows to wait for a reader to be opened.
Couldn't we implement the timeout at a higher level then?  It's confusing currently, because in ReadWithTimeout(), a timeout value of 0 means block indefinitely, and in OpenAsWriterWithTimeout(), it means just return an error.

Maybe OpenAsWriter() can simply return an error and you can implement the retry at a higher level?   It could return an error from the generic category indicating that the reader hasn't opened yet, and then Windows can do the same, so that the retry logic could be written at a higher level.

Reading and writing are a little different in that with a Read, the most common use case is to block until its finished, and you very rarely want to return immediately and do something else if there's no data.  So it makes sense for ReadWithTimeout() to use 0 == INFINITE, but then OpenForWriteWithTiemout() becomes confusing.

Thoguhts?

http://reviews.llvm.org/D6954

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/