https://linen.dev/ logo
Join Discord
Powered by
# general
  • c
    On windows though, is WSL actually more "costly" than a VM?
  • c
    although NTFS 😔
  • b
    Probably, is my guess
  • b
    Not as good as native
  • b
  • b
    as per our discussion yesterday
  • b
    patch 1 can be ignored, patch 2 is identical to the one I did (lol)
  • b
    but I like the query interface better
  • c
    not sure I agree, to me it seems like a more complicated interface which is harder to reason about
  • c
    I don't understand the need for the additional 
    IO_URING_QUERY_OPCODES
    enum with the additional 
    io_uring_query_hdr
    arguments over the versioned struct approach tbh
  • a
    What is the purpose of 
    sigmask_sz
    in 
    io_uring_getevents_arg
    ?
  • b
    it's mean to replace the probe variant, so basically a fuller interface for both the new bits we discussed yesterday, but also serve as the probe interface. which I do think is a good thing. I'll spend some time later today playing with this and see where we end up
  • c
    Hmm
  • a
    I can't seem to make the 
    io_uring_enter
    sigmask argument work. I have this SIGPIPE coming from a socket write that comes through 
    io_uring_enter
    . If I use 
    pthread_sigmask
    to mask it, the signal goes away. If I use the supposedly equivalent sigmask argument, it still comes through.
  • b
    what does your io_uring_enter() call look like?
  • a
    Copy code
    CPP
    sigset_t sigset_1;
    vsm_verify(pthread_sigmask(SIG_BLOCK, nullptr, &sigset_1) == 0);
    debug_print_sigset("old", sigset_1);

    vsm_verify(sigaddset(&sigset_1, SIGPIPE) == 0);
    debug_print_sigset("new", sigset_1);

#if 0
    // Use pthread_sigmask to block SIGPIPE temporarily:

    sigset_t sigset_2;
    vsm_verify(pthread_sigmask(SIG_BLOCK, &sigset_1, &sigset_2) == 0);

    struct sigset_cancel
    {
        sigset_t* sigset;

        ~sigset_cancel()
        {
            vsm_verify(pthread_sigmask(SIG_SETMASK, sigset, nullptr) == 0);
        }
    };
    sigset_cancel sigmask_cancel;
    sigmask_cancel.sigset = &sigset_2;
#endif

    fprintf(stderr, "enter-1\n");
    int const r = io_uring_enter(
        static_cast<unsigned>(io_uring_fd),
        to_submit,
        min_complete,
        flags,
        &sigset_1);
    fprintf(stderr, "enter-2\n");
  • a
    Copy code
    sigset (old):
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
sigset (new):
  00100000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
  00000000000000000000000000000000
enter-1
vasama@desktop:~/c/allio/build/gcc-asan/Debug$ echo $?
141
  • a
    Oh, no, I think I've misunderstood how signal masking works. Even if it's masked, it still gets raised when unmasked.
  • a
    But that leaves me with a new question: what is the use case for the sigmask argument in 
    io_uring_enter
    ?
  • b
    Hmm, out of curiosity, is it normal for localhost tcp zc send to actually copy?
  • b
    I was casually re-reading the docs today and saw that we could introspect the send nowadays
  • b
    This assertion is tripping for me in my tests: 
    assert!(cqe.res != liburing_rs::IORING_NOTIF_USAGE_ZC_COPIED as _);
    Tbf, I am using really small sends in my unit tests so my guess is that it's better to copy for small buffers and do real zc for large buffers
  • b
    Maybe I just need another unit test for large sends, at like 256kb or something
  • b
    it is yes, on linux localhost is an odd concoction. so yes, you won't have zc working there
  • b
    Awesome. Thanks!
  • h
    Hi @gorgeous-horse-28122 , I was wondering: Is it expected that zc rx still works if the 
    if_rxq
    queue-id in 
    io_uring_zcrx_ifq_reg
    is different from the queue setup via flow-steering? In my test, the socket is still receiving the data.
  • g
    you'll receive the data but it'll be copied
  • c
    @better-helmet-21984 I remember a while ago you mentioned fsync & sync_file_range require a blocking issue (so they're on the worker pool?) I assume FUA writes are not impacted in the same way, right?
  • b
    correct
  • c
    Lovely