Missing event loop features from Python 3.7+

[ntninja]

Is your feature request related to a problem? Please describe.
gbulb has not kept up with any newer features introduced by asyncio since Python 3.7 – some of these work anyways since they are provided by asyncio.BaseEventLoop, but some are just plain missing or are broken.

Describe the solution you'd like
Somebody has to implement that stuff, but at the very least it should be documented. (What I’m doing here… 😉)

Additional context
Here’s the list of what’s missing/broken (possibly incomplete of course):

• loop.create_unix_connection & loop.create_unix_server (Python 3.5+?) appear to be absent, although they have always been present in asyncio
• loop.sendfile & loop.sock_sendfile (Python 3.7+) – unless the fallback parameter is set to False these will work, but actually use an emulation based on repeated read/write calls also used on Windows and for TLS sockets on all platforms (so they’re kinds pointless with gbulb)
• loop.sock_recv_into & the accompanying support for BufferedProtocol (Python 3.7+) – plain missing, BufferedProtocol instances are mistaken for plain Protocol instances and cause crashes
• TimerHandle (Python 3.7+) – gbulb actually returns a GLibHandle instance in all cases that derives from Handle, so it’s really just missing the .when() method for objects returned from loop.call_later and loop.call_at
• loop.sock_recvfrom, loop.sock_recvfrom_into & loop.sock_sendto (Python 3.11+) – missing

[ldo]

It seems to me these needs point up flaws in the existing asyncio architecture. There is no reason why they need to be implemented anew for every event loop subclass: they should really be provided, automatically, by the base machinery in asyncio itself.

[ntninja]

@ldo: That is unfortunately incorrect. Some new things where actually inherited by the asyncio base class, but all the things above have to be provided by each event loop separately since they need special handling under Windows/IOCP: On this platform the event loop implementation needs to maintain an OVERLAPPED structure that is then passed to each read/recv/recvmsg/sendto/connect/… call.

Background: The readiness-based I/O predominantly used on Unix platforms would allow the asyncio framework code to just ask the event loop implementation to poll a file descriptor for reading/writing and then perform the actual target operation itself once the file descriptor becomes ready. The completion-based I/O required by Windows/IOCP however, actually requires the event loop implementation code to initiate the operation itself so that it can maintain the relevant state to associate any received completion events with the originally started operations. The same is true for Posix AIO and Linux’s more recent io_uring interface (neither of which the current asyncio default event loops currently use though). If gbulb completely removed its remaining Windows support it could actually derive from the undocumented BaseSelectorEventLoop or _UnixSelectorEventLoop classes to get most of this stuff for free.

[ldo]

Core asyncio provides add_reader() and add_writer()] methods, which should be sufficient for managing any additional file descriptors in POSIX.

Isn’t Windows supposed to be POSIX-compatible?

[stuaxo]

I think Windows was POSIX-compatible for a very old version of POSIX; and even then it was a bit less than the bare minimum; they made "Services for Unix" to advertise POSIX, so the POSIXness isn't even in the Windows bit that matters (SFU isn't even a thing any more anyway).