Re: [Nbd] another?

[Alex Bligh <alex@...872...>]

--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 :-)

This should never happen even with the existing server (and I've never
seen it happen). It might be a bug in my test suite of course.

The integrity test should only be writing to the socket if FD_ISSET
returns true. It then (possibly naughtily) does a write() in a loop,
which may in effect block if the socket buffer is full, which will
stop it reading replies.

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?

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.

--
Alex Bligh