Ahh, sorry. Ignore this most recent post. That's in the Disconnect method. The initial questions still stand though.
On Thu, Oct 2, 2014 at 3:23 PM, Zachary Turner <ztur...@google.com> wrote: > There's a comment that says this: > > // Try to get the ConnectionFileDescriptor's mutex. If we fail, that > is quite likely > // because somebody is doing a blocking read on our file descriptor. > If that's the case, > // then send the "q" char to the command file channel so the read will > wake up and the connection > // will then know to shut down. > > 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? > > On Thu, Oct 2, 2014 at 2:22 PM, Zachary Turner <ztur...@google.com> wrote: > >> 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. >> >> 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. >> >> >> >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
