[HN Gopher] Io_uring is not an event system (2021)
       ___________________________________________________________________
        
       Io_uring is not an event system (2021)
        
       Author : signa11
       Score  : 31 points
       Date   : 2025-09-30 10:43 UTC (3 days ago)
        
 (HTM) web link (despairlabs.com)
 (TXT) w3m dump (despairlabs.com)
        
       | PunchyHamster wrote:
       | >io_uring is not an event system at all. io_uring is actually a
       | generic asynchronous syscall facility.
       | 
       | It's not an event system at all! It's an event system!
       | 
       | The type of events being subset of all possible events in system
       | does not make it not events system. Nor it being essentially a
       | queue
        
         | ciconia wrote:
         | It's not an event system in the sense that it's not just a way
         | to get notified when a file descriptor is ready for reading or
         | writing. Like the OP says, it is a way to run syscalls
         | asynchronously.
        
           | jcelerier wrote:
           | > It's not an event system in the sense that it's not just a
           | way to get notified when a file descriptor is ready for
           | reading or writing.
           | 
           | first time in my life I hear people calling this an event
           | system. For me it's always been any architecture centered
           | around asynchronous message queues.
        
             | hxtk wrote:
             | Event-Driven Architecture refers to a different thing, but
             | people used to refer to async code as event-based back
             | before async/await existed, when doing async meant writing
             | the Event Loop yourself.
        
           | Sharlin wrote:
           | Yes, but "fd readiness checker" is a super narrow nonstandard
           | definition of "event system". Though I get what the author
           | tries to say.
        
       | lordnacho wrote:
       | I thought the main selling point was that you could tell the
       | system "when you finally get this response, run this function on
       | it"
        
         | ciconia wrote:
         | There are no callbacks in io_uring. You submit an operation
         | (SQE), the kernel runs your request while you're doing other
         | stuff, eventually you get back a completion entry (CQE) with
         | the results of the operation.
        
           | Muromec wrote:
           | Sounds like a callback to me
        
             | vlovich123 wrote:
             | Saying it's a callback is equivalent to claiming select is
             | a callback. Receiving an event does not a callback make -
             | providing the function address to invoke would make it a
             | callback.
        
             | Veserv wrote:
             | Callback execution is: wait until begin event occurs, then
             | do this operation.
             | 
             | Asynchronous execution is: do this operation, then wait
             | until finish event occurs.
             | 
             | They are opposites.
        
         | lstodd wrote:
         | The kernel can't "run a function". It can only wake a thread
         | sleeping on a syscall. This is called blocking IO.
         | 
         | The whole point of async is to find a compromise between
         | context switch cost and event buffering and the latency
         | resulting from the latter. It is not about "running a
         | function".
        
           | lukeh wrote:
           | io_uring can also use an eventfd to signal you need to check
           | the completion queue. We use this with libdispatch to run a
           | clang block on completion (the block is stored in the
           | user_data). Admittedly this is a very specific use case.
        
           | touisteur wrote:
           | There is limited chaining capability in io_uring that can be
           | an actual gamechanger if your chain of ops can be fully in-
           | kernel.
           | 
           | An intern of mine wrote a whole tcp-checkpoint-(pause-
           | ingress-and-egress-and-the-socket-save-all-state-unpause-
           | everything)-and-send-full-state-on-other-socket (which was a
           | dozen or so ops - netlink writes, ioctls, set/getsockopt,
           | read/write calls...) in a chain - all in one command-queue-
           | write IIRC.
           | 
           | Performance was as good as an ad-hoc kernel module, without
           | any ebpf. We just had one kernel patch to handle some
           | unhandled syscall (getsockopt ? Setsockopt ? Ioctl?) (that we
           | sadly didn't upstream... 2 years ago) and we were done.
           | Really a great system for batching syscalls.
           | 
           | It made me wish for a form of DAG for error-handling or for
           | parallel operations in chains...
        
           | themafia wrote:
           | > The kernel can't "run a function".
           | 
           | What is a signal handler?
        
       | kiitos wrote:
       | "event system" is any mechanism where events (readiness,
       | completion, signals, GUI messages) drive control flow,
       | restricting "event system" to descriptor readiness exclusively is
       | the author's personal framing, not exactly common parlance
        
       ___________________________________________________________________
       (page generated 2025-10-03 23:00 UTC)