Re: [Nbd] another?
- To: Alex Bligh <alex@...872...>
- Cc: nbd-general@...72...
- Subject: Re: [Nbd] another?
- From: Wouter Verhelst <w@...112...>
- Date: Fri, 16 Sep 2011 13:35:06 +0200
- Message-id: <20110916113506.GV19601@...3...>
- In-reply-to: <4174751764B4DC4C2F6DACAD@...873...>
- References: <CAFDOyVDgN4Zo0=LDnWbJ5zBPb9gmLgg-80kuqpN6TjKWGbpRSw@...18...> <3910BC1A8D0D52DED33F94E3@...873...> <CAFDOyVBXr=nAMH7jRorSHBKFMskXbfPnkD7XwDvL5ZZxPp402A@...18...> <20110916083445.GB19601@...3...> <955E7D4A79C020EE6FC1B797@...873...> <20110916103623.GU19601@...3...> <4174751764B4DC4C2F6DACAD@...873...>
On Fri, Sep 16, 2011 at 12:12:44PM +0100, Alex Bligh wrote:
> --On 16 September 2011 12:36:23 +0200 Wouter Verhelst <w@...112...> wrote:
> >>Is this some form of deadlock you are talking about?
> >Yes; both sides of the conversation are waiting on the other to read.
> >It'll be fixed once one end will be able to read and write
> >simultaneously, and my multithreaded implementation is capable of doing
> >so. It just needs to actually /work/, before I can release it :-)
>
> It is theoretically possible that the read will not take place because
> the server is waiting to write back (large read replies) which
> will end up in the same loop.
>
> I've never seen that one happen, but on reflection it is indeed
> possible. Is that what you are seeing?
Yes. I've not seen it happen on my own laptop, but it does happen fairly
easily on Debian GNU/kFreeBSD (which is why I disabled it, since
kFreeBSD is a release architecture for Debian), and on some of the other
Debian architectures (but I don't remember off-hand which ones).
> Two things occur to me:
>
> 1. Perhaps the tester client and the server should be attempting
> to fiddle with SO_SNDBUF and SO_RCVBUF?
>
> 2. If this is really happening (and I confess to surprise) then the
> real problem is that my tester program is not doing truly non-blocking
> I/O. I should fix it so it does (which is easy enough, I'll just do
> every write to a RAM buffer and put every read through a RAM buffer).
> Then even if a write stalls half way through the data it will continue
> to read stuff from the socket.
No, I think this should be fixed in the server, not the tester client.
This is a condition that the server needs to be able to deal with. The
fact that it doesn't is a bug in the server which the tester client only
exposed, it's not a bug in the tester client. If anything, it's a
feature of the tester client that it exposes a bug in the server.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: