test_wantWriteError fails again because not enough data is written

[nh2]

Similar to #37, #67, #76.

On my Ubuntu 16.04, (and I think when I build my libraries against musl instead of glibc, using nix, but that's probably not relevant), I get:

=================================== FAILURES ===================================
______________________ TestConnection.test_wantWriteError ______________________

self = <tests.test_ssl.TestConnection object at 0x7fffe9eabd10>

    def test_wantWriteError(self):
        """
            `Connection` methods which generate output raise
            `OpenSSL.SSL.WantWriteError` if writing to the connection's BIO
            fail indicating a should-write state.
            """
        client_socket, server_socket = socket_pair()
        # Fill up the client's send buffer so Connection won't be able to write
        # anything.  Only write a single byte at a time so we can be sure we
        # completely fill the buffer.  Even though the socket API is allowed to
        # signal a short write via its return value it seems this doesn't
        # always happen on all platforms (FreeBSD and OS X particular) for the
        # very last bit of available buffer space.
        msg = b"x"
        for i in range(1024 * 1024 * 4):
            try:
                client_socket.send(msg)
            except error as e:
                if e.errno == EWOULDBLOCK:
                    break
                raise
        else:
            pytest.fail(
>               "Failed to fill socket buffer, cannot test BIO want write")
E           Failed: Failed to fill socket buffer, cannot test BIO want write

tests/test_ssl.py:2593: Failed
===================== 1 failed, 490 passed in 7.54 seconds =====================

This looks like, as in the other issues, my kernel actually permits more data in a socket buffer than 1024 * 1024 * 4.

It looks that this test cannot be written so that it passes on all systems, unless it either

• figures out what the actual max socket buffer size is before testing it, or
• really counts up forever (e.g. possibly up to the amount of RAM available) to accomodate for any setting the system that this running on might have

[nh2]

CC @dtzWill via NixOS/nixpkgs#42180 (comment)

[reaperhulk]

We’d be happy to review a patch to resolve this but (speaking for myself) I don’t have the bandwidth to work on a fix

[dtzWill]

b2777a4 looks related! Don't suppose that addresses this for you, @nh2? :)

[nh2]

That does work around it for my configuration, nice find. But still the success of this test depends on sysctl settings, so a real fix that works everywhere must detect it or probe it arbitrarily high.

[alex]

Good enough for government^W open source work.