Add support for io_uring

[lpereira]

• https://kernel.dk/io_uring.pdf

[lpereira]

Thoughts about this:

• The current method of performing I/O and polling for completeness has to be kept there for compatibility with older Linux kernels and other operating systems where io_uring isn't supported.
• The GCC extension for ifuncs can be used here to determine which version to be used during startup: the resolver function probes the Linux kernel version and returns a pointer to a function that will either use the "legacy" way of performing I/O, or something that uses uring
• A macro can be used to implement these functions in such a way that 3 versions can be provided: only-epoll, only-uring, autodetect. This way, if one knows that Lwan will be built and executed on a certain environment, they don't have to pay the price for indirect function calls.

[mrakh]

Apologies in advance for necro'ing this issue, but one thing to consider is that ifuncs are specific to glibc. Using them means lwan would no longer compile with musl, cosmopolitan, or any other alternative libc. I would suggest instead to use __attribute__((constructor)) for resolving at startup - something like this:

#if defined(SUPPORT_URING)
inline
#endif
static void my_func_impl_io_uring() {
    // ...
}

#if defined(SUPPORT_EPOLL)
inline
#endif
static void my_func_impl_epoll() {
    // ...
}

#if defined(SUPPORT_URING)
void my_func() { my_func_impl_io_uring(); }
#elif defined(SUPPORT_EPOLL)
void my_func() { my_func_impl_epoll(); }
#else
void(*my_func)();
__attribute__((constructor)) static void resolve_my_func() {
    long major;
    long minor;
    // major, minor = uname(...)
    if(major > 5 || (major == 5 && minor >= 1))
        my_func = my_func_impl_io_uring;
    else
        my_func = my_func_impl_epoll;
}
#endif

[lpereira]

Apologies in advance for necro'ing this issue, but one thing to consider is that ifuncs are specific to glibc. Using them means lwan would no longer compile with musl, cosmopolitan, or any other alternative libc. I would suggest instead to use __attribute__((constructor)) for resolving at startup - something like this:

Yes, that's also a possibility. It'll take a long while before either handmade resolvers or ifuncs are used though -- I haven't been working that hard on Lwan for a while now. (Unless you're interested in implementing this -- in which case, feel free to ask questions if you end up getting stuck.)