[lldb-dev] ConnectionFileDescriptor and thread safety

[Zachary Turner]

Because it doesn't actually serialize reads, it just fails if another
thread is already reading.  So in that sense it's basically a glorified
assertion.  I later discovered that the more likely reason for it is so
that a Read() doesn't begin while a Disconnect is in progress.  Ultimately
I was trying to figure out if I needed the same mutex in my windows
implementation.  It looks like we assume that two reads never happen
simultaneously from different threads.  If they did, there would be an
error unless one thread re-tried, and nobody does.  So read doesn't need to
be thread safe with itself, only with disconnect.  I implemented that
without a mutex on Windows, so I think my question is resolved.

On Tue, Oct 7, 2014 at 5:04 PM, Greg Clayton <gclayton at apple.com> wrote:

> The mutex is just to stop multiple threads from reading right now. One
> thread locks the mutex and gets to read and the other thread will fail
> instead of blocking. What is hard to understand about this?
>
>
>
> > On 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/20141007/27bc7347/attachment.html>