Re: [Nbd] Testing NBD server implementations for correctness
- To: Wouter Verhelst <w@...112...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>
- Subject: Re: [Nbd] Testing NBD server implementations for correctness
- From: Alex Bligh <alex@...872...>
- Date: Mon, 26 Sep 2016 11:41:06 +0100
- Message-id: <7AF202A4-2702-40F1-8A61-F2807F6D0D91@...872...>
- In-reply-to: <20160925210518.6dmxvue2bsvi7mag@...3...>
- References: <57E74AFB.4070506@...2724...> <5720E25C-93C9-4DDB-B871-93DC5BA9CD5F@...872...> <20160925112411.byjfmv7qotamd7m4@...3...> <EA976193-41B3-4322-AFE5-8E01B1BF1002@...872...> <20160925210518.6dmxvue2bsvi7mag@...3...>
Wouter,
> On 25 Sep 2016, at 22:05, Wouter Verhelst <w@...112...> wrote:
>
> On Sun, Sep 25, 2016 at 01:58:06PM +0100, Alex Bligh wrote:
>>
>>> On 25 Sep 2016, at 12:24, Wouter Verhelst <w@...112...> wrote:
>>>
>>>>>
>>>>> From memory "make check" runs all the tests, though I think it
>>>> skips the 'huge' integrity test.
>>>
>>> Indeed, because that sometimes deadlocks.
>>
>> Really? I thought it merely took ages. I'd be interested to
>> know why it deadlocks, and whether that's a server bug
>> or a test bug.
>
> Probably fixed by now, actually -- at least with the reference
> implementation.
>
> 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 :-(
> 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
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 :-)
> (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.
Alex
>
> --
> < 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
>
--
Alex Bligh
Reply to: