https://linen.dev/ logo
Powered by
# general
  • b
    makes sense
  • r
    actually... if I really focus in...I dont understand blocking. so thats what I am reading up on now
  • b
    the very first versions looked like that, now it exclusively relies on whether or not you can a) issue in a non-blocking fashion, and b) get a callback when it's either complete, OR when it should be retried
  • b
    and if b) isn't a thing for that type of file or operation, THAT'S when it goes to the io-wq threadpool
  • b
    it strictly exists as a fallback
  • b
    and good uses of io_uring for storage or networking will never see io-wq used, at all
  • b
    blocking is really just "you have to wait for this operation" and hence the task gets put to sleep and scheduled out
  • r
    yeah hearing you say that in the talk was a wtf moment for me.
  • r
    I went back in the video etc
  • b
    it's one of those stubburn urban myths
  • b
    I'm glad I reached at least one with it 🙂
  • b
    You know what was low-key surprising to me was that kernel code actually isn't that bad to read
  • b
    As a humble userspace developer, I think the kernel is a very daunting thing
  • b
    On some level, it's kind of amusing how it really is all just C
  • b
    yeah it's all just basic C end of the day
  • r
    appreciate the pointers everyone. been reading how blocking syscalls work, how sqpoll works, looking at liburing code... In short, I had a lot of misconceptions about how io_uring actually worked.
  • b
    should probably write this up in a doc
  • b
    I'm always surprised how people ask for the old io_uring pdf
  • b
    which is no longer really relevant
  • b
    but an architecture overview might be a useful thing to have
  • b
    Heck yeah! I'd really like to read that too
  • b
    me too
  • b
    great, guess I just signed up for doing some more work 😉
  • r
    happy to help, at least in the capacity of "that's not clear" or "does that mean X?" proof-reading
  • b
    would certainly want to rope in folks for proof reading
  • c
    can a client connection theoretically monopolize all the provided buffers when we issue a multishot receive on its socket?
  • c
    i guess i'm asking more about prioritization within io_uring, is it first come first served or does the ring try to be fair in its distribution of buffers among the connected sockets
  • b
    you can set a recv cap per invocation
  • b
    I know who added this feature 😜
  • b
    But yeah it’s a real issue