10 ms·

The issue has been identified before, but seems like it stalled: https://gitlab.freedesktop.org/libinput/libinput/-/issues/509 https://gitlab.freedesktop.org/li

• tankenmate 5y ago
  I just did a quick check the posted fix is not in the most recent -rc branch in the public git repo.
  • londons_explore 5y ago
    This is the issue with using mailing lists... Large numbers of perfectly good fixes, embodying many hours of effort, just get missed and forgotten about. At least with GitHub PR's, every request either needs to be merged or rejected.
    • loeg 5y ago
      I’m no fan of mailing lists, but GitHub PRs get ignored in much the same way.
      • misnome 5y ago
        There’s ignored, and there is “not aware that it’s unresolved”. How do mailing list flows handle the “give me a list of open patches”?
        • colonwqbang 5y ago
          People treat emails like tickets, representing things that should be done. They put them in particular email directories depending on their personal workflow. When they are either done or rejected, they delete the email, archive it, or mark it as read. It's not unlike the github workflow except that it's up to each person to define the way they prefer to work. Not a single policy that's decided by the project owner. Planning/tracking also happens more in private instead of public. You may think that's worse, but perhaps you can also see why some might prefer it?
    • Denvercoder9 5y ago
      The modern trend is autoclosing PR's after they haven't had any activity in X months, so there's not much difference with mailing lists anymore...
• CyberRabbi 5y ago
  What the proposed patch does is delay a specific latent operation to an asynchronous context so that close() doesn’t block on that operation (which is freeing some memory). The proposed patch isn’t a comprehensive fix, it admits there are still other sources of relatively high close() latency. So that got me thinking, there is no way to fix this “bug” because there is no specification on how long close() should take to complete. As far as we are promised in user-land, close() is not an instantaneous operation. close() is a blocking operation! Even worse, it’s an IO operation. So now I think the bug is in the application. If you want to avoid the latency of close() you should do it asynchronously in another thread. This is similar to the rule that you should not do blocking IO on the main thread in an event-loop based application.
  • touisteur 5y ago
    Or, io_uring the thing. One could probably wrap close() with LD_PRELOAD and not touch the binary...
    • CyberRabbi 5y ago
      While tempting, you can’t generally fix this by simply patching close() with some function that converts it to an unchecked asynchronous operation. If that were the case, you could just do that in the kernel. Close() is expected to complete synchronously. This matters because posix guarantees that open()/pipe() etc. will return the lowest file descriptor not in use[1]. I.e. this should work: close(0); fd = open(“/foo/bar”, …); // fd is guaranteed to be 0 If you made close() just dispatch an asynchronous operation and not wait on the result, then the code above would break. Any code that uses dup() likely has code that expects close() to behave that way. The other issue is that close() can return errors. Most applications ignore close errors but to be a robust solution you’d need to ensure the target application ignores those errors as well. [1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_14 https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...
      • deleted 5y ago
        [deleted]
• satnome 5y ago
  Just curious, how did you nail it down to that specific issue and patch? That seems like a great skill to have.
  • nisegami 5y ago
    With git, the command git bisect provides a mechanism for using binary search on a range of commits.