Re: [Nbd] Testing NBD server implementations for correctness

[Wouter Verhelst <w@...112...>]

On Mon, Sep 26, 2016 at 11:41:06AM +0100, Alex Bligh wrote:
> Wouter,
> > On 25 Sep 2016, at 22:05, Wouter Verhelst <w@...112...> wrote:
[...]
> > The client and the server were both single-threaded, and would only swap
> > between "reading from socket" and "writing to socket" once a read or
> > write operation was completely finished. As such, if one side filled up
> > its TCP buffer, it would block until the other side would start to read
> > from it. Since both sides do so, the possibility exists for both sides
> > to end up in a blocking state.
> 
> Ah OK. Interesting. That was one of the things it was designed to test
> and I never got it to hang with the reference implementation :-(

Well, I did :-)

> > But with the GThreadPool thing, the server can now read and write at the
> > same time (in different threads, obviously), which means that that
> > deadlock should be gone.
> > 
> > I'll probably enable the integrityhuge test for Debian with my next
> > upload; if it doesn't break, I'll enable it for master, too.
> > 
> >> I rewrote that test suite more comprehensibly in golang for
> >> gonbdserver if you are interested.
> > 
> > What do you mean by "more comprehensively"?
> 
> Not 'more comprehensively', but 'more comprehensibly'. The code

Oh, okay. It was a bit late last night, I guess :-)

> is written using goroutines and is easier to understand than the
> non-multithreaded select loop and state machine C horror that I
> wrote the first time :-)

Yes. I understand how most of nbd works, but that is probably the one
thing I have always had trouble understanding. My usual answer to "how
do I deal with the integrity test" is "let's not". I obviously
must've understood it at some point (because I merged it, and I'm not in
the habit of merging code I don't understand), but it's pretty terrible
to grok.

Perhaps that code should be rewritten at some point. Not now, though.

> > (also, not sure if switching the test suite to a whole different
> > language is necessarily a good idea, but I can probably be convinced
> > otherwise...
> 
> Not necessarily suggesting you should (though you are welcome
> to) - it was written to test gonbdserver.

Right.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12