[lldb-dev] ConnectionFileDescriptor and thread safety

[Zachary Turner]

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 <zturner at 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 <zturner at 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.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141002/75b36ed1/attachment.html>