<div dir="ltr">Ahh, sorry.  Ignore this most recent post.  That's in the Disconnect method.  The initial questions still stand though.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 3:23 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There's a comment that says this:<div><br></div><div><div>    // Try to get the ConnectionFileDescriptor's mutex.  If we fail, that is quite likely</div><div>    // because somebody is doing a blocking read on our file descriptor.  If that's the case,</div><div>    // then send the "q" char to the command file channel so the read will wake up and the connection</div><div>    // will then know to shut down.</div></div><div><br></div><div>This is a little confusing to me.  Thread A does a blocking read.  Thread B tries to do another blocking read.  The correct way to handle that is by shutting down the connection?  Is this an actual intended use case, or just trying to handle some sort of exceptional condition?</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 2:22 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>What are the thread safety assumptions of ConnectionFileDescriptor?  There's a mutex in ConnectionFileDescriptor::Read(), but it almost seems pointless.  All it does is do a TryLock() and then return an error if it fails.  I sincerely doubt anyone is actually handling this error, so this implies to me that it's intended to not be used concurrently from multiple threads and this is just used to catch the error in case anyone messes up.</div><div><br></div><div>But this leads to something else that I don't understand.  Do we actually care to support regular on-disk files with this class, or do we only care about sockets and pipes?  We do seem to have support for a file://PATH connection string, so someone thinks this is useful.  But how would it even work without being able to either seek or specify the offset?  Are you expected to use a different fd for the reading and writing side and never mix calls to Read() and Write() on the same Connection instance?  If so, maybe we need to make this explicit with InboundConnection and OutboundConnection or something like that.</div><div><br></div><div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>