Using "recvmsg" with anyio

[smurfix]

Using wait_socket_readable fails when using asyncio.

Seems that asyncio decides to add a socket reader as soon as the socket is opened – which causes BaseSelectorEventLoop._ensure_fd_no_transport to go splat when I try to check for readability.

This test program succeeds with trio, but not with asyncio:

#!/usr/bin/python3

# boring stuff
import anyio
PORT=59493
async def main():
    async def handler(sock):
        await sock.send(b'123')
        await anyio.sleep(9999)
    async def server(evt):
        listener = await anyio.create_tcp_listener(local_port=PORT)
        await evt.set()
        await listener.serve(handler)

    async with anyio.create_task_group() as tg:
        evt = anyio.create_event()
        await tg.spawn(server, evt)
        await evt.wait()
# boring stuff ends

        async with await anyio.connect_tcp('localhost', PORT) as client:
            sock = client.extra(anyio.abc.SocketAttribute.raw_socket)
            await anyio.wait_socket_readable(sock.fileno())
            data, aux, *_ = sock.recvmsg(4096,1024)
            assert data == b'123', data

            await tg.cancel_scope.cancel()
anyio.run(main, backend="asyncio")

I'm doing this because depending on the options it's called with, the library I'm anyio-izing may need to pass file descriptors along.

[agronholm]

Yeah, wait_socket_readable() and wait_socket_writable() are not kosher when used on already-wrapped sockets and cannot be expected to work. Perhaps this should be mentioned in the documentation.

You mention passing file descriptors, but that's only possible with UNIX sockets, not TCP. What gives?

[smurfix]

Nothing gives, I was lazy and used a TCP example to illustrate the problem because I had that lying around.

WRT asyncio one might expect that calling pause_reading on the thing would be sufficient for something else to be granted access to the socket, but that would probably be too easy … there's also no way to cleanly un-wrap a socket; I can dup() it, but attempting to close the original calls shutdown, so I'd have to keep that around too. Bah.

[agronholm]

Supporting recvmsg() has been on my private to-do list for a while but up until now nobody has asked for it.

[agronholm]

Would it be enough for it to be part of the 3.0 release? I don't really want to add any more features to the 2.x branch.

[smurfix]

Sure, no problem. The code I'm adapting is going to rely on 3.0's sync-calling features anyway.

[agronholm]

I can probably support the narrow use case of sending and receiving a bunch of file descriptors over UNIX sockets, but general recvmsg support in SocketStream is a no-go.

[agronholm]

Oh boy. Turns out I have to completely abandon the existing asyncio SocketStream class for UNIX sockets if I want to support this. If a Transport is holding on to a socket, it cannot used for anything else, period. And since asyncio does not support sendmsg() in any way...

[agronholm]

Whew, that was a load of work. A new proof-of-concept UNIX socket stream and listener have been successfully tested.

[agronholm]

The test suite now passes with the new UNIXSocketStream and UNIXSocketListener implementations. I'll make a PR once I've added new tests for the receive_fds() and send_fds() methods.

[smurfix]

A heap of thanks for doing that work.