5 ms·

Linux was the last to implement "events", they had IO completion ports and kqueue to learn from. They decided to implement something broken and document it as s

Linux was the last to implement "events", they had IO completion ports and kqueue to learn from. They decided to implement something broken and document it as such, it was right in the man page. I find that astonishing. That reminds me, dnotify and inotify are probably still there. I'm bitter because I've had to port a clean kqueue event loop to Linux as a younger programmer and it was a dreadful experience.

nextaccountic 4y ago
Is inotify broken? What should be used instead of it to watch for filesystem events?
- rwaksmunski 4y ago
  I don't know man, I've given up and handed it over to someone more senior. Their port was half the performance and the project was killed. We kept on using FreeBSD for the product.
  - nextaccountic 4y ago
    Is it broken regarding to correctness or just performance? I mean, does inotify have some obscure race condition or drop events or duplicate events or something
    - rwaksmunski 4y ago
      > Is it broken regarding to correctness or just performance? Yes. This blog entry explains it much better then I could: https://wingolog.org/archives/2018/05/21/correct-or-inotify-pick-one https://wingolog.org/archives/2018/05/21/correct-or-inotify-...
  - Beltalowda 4y ago
    For watching filesystem events FreeBSD's kqueue is much more difficult to use correctly though, and in my experience it certainly doesn't outperform inotify. inotify (and now, fanotify) are specifically designed to watch for filesystem events, whereas kqueue is a generic event system used for many things. In many ways that's better, but it this lack of specialisation also comes with some drawbacks.
    - rwaksmunski 4y ago
      From what I can recall, the performance issues were on the network side. I suspected accept() calls not scaling right, but instrumentation on Linux was quite poor at that time. They had nothing like dtrace back then so I can't be certain.
- jgerrish 4y ago
  Jesus, is it sad when I hear senior now I don't dream of leading the design of big systems? I think of stakeholder meetings and fighting business requirements? I had an inotify project in process for creating a better developer experience. Seeing this hit Hacker News tells me it's a fucking political landmine. Sigh. Don't worry, I'll have the strength to argue the proper technical solution that still satisfies business needs. That's the important thing!
  - nextaccountic 4y ago
    I don't understand what you mean. Anyway I used inotify multiple times in various programming languages and it was always fine, I'm a bit surprised that it's considered "broken" in any way. I mean, is it broken regarding to correctness or just performance?
    - jgerrish 4y ago
      I don't consider it broken, I was referring to political will to build the healthy base of a developer ecosystem. But, you've inspired me to do a deeper historical and technical deep dive of the filesystem event space. Thank you. Have a great weekend!
      - jgerrish 4y ago
        And I do understand. I am one who reached out. Thank you for showing me. They understand who I am. Have a good week!
- mastax 4y ago
  http://wingolog.org/archives/2018/05/21/correct-or-inotify-pick-one http://wingolog.org/archives/2018/05/21/correct-or-inotify-p...
  - nextaccountic 4y ago
    Thanks! Does fanotify fix those issues?
    - scaramanga 4y ago
      Lose events due to inotify buffer overflow, or provide backpressure on entire vfs and allow a watcher to DoS the entire system. Pick one. Similar "minor implementation issues" occur when considering how to fix all of the other "bugs." It's fine if you don't like the design trade-offs of a particular solution. But pretending that they aren't trade-offs, or they aren't valid choices, is just going to leave people shaking their heads at you. Edit: and by "you" i mean the authors of these articles. Although I think Marek is a very talented guy and probably just a bit hyperbolic with his titles.
ajross 4y ago
Was your experience the same thing as the linked article? I mean, reading this as someone who knows epoll and not kqueues quite as much, it sounds very much like "I tried to use this API like something I already know and it didn't work, so I hate it and it's broken". The linked article basically goes through a bunch of scenarios examining clumsy ways to chase a slightly-obscure requirement ("wake up exactly one thread per event using a single descriptor") just to land in the very last paragraph on the clearly correct solution ("just use ONESHOT, that's what it's for!"). I mean, there's literally a feature right there in the man page[1] that does exactly what the author wants. They just didn't want to learn about it and view their ignorance as a bug in the software. Meh. This gets tiresome. As the article linked yesterday points out, epoll() is the "API that powers the internet", and has effectively solved the C10k problem for everyone that has it. But yeah, you need to read the man page. [1] No, seriously, it's right there in the man page, discussing exactly this scenario and how to avoid it.
- rwaksmunski 4y ago
  I've had to deal with forks and threads, epoll and inotify. It was beyond my skills at the time.
- naasking 4y ago
  > No, seriously, it's right there in the man page, discussing exactly this scenario and how to avoid it. The point is, do all of the other configurations for epoll have legitimate usecases justifying the complexity and need for those parameters? The kqueue design scales from single-threaded to multithreaded scenarios without issue and without all of these pitfalls, so why not just adopt that design? Why does the specific issue need to be a solution described in the man page at all? > As the article linked yesterday points out, epoll() is the "API that powers the internet", and has effectively solved the C10k problem for everyone that has it. Being able to solve a problem and doing it well are not the same. The latter arguably deserves criticism.
  - ajross 4y ago
    > The latter arguably deserves criticism. Ahem. The headline under discussion is "fundamentally broken", which given the context you've granted, sounds closer to a lie than the truth to me. Meh. OS advocates will always have their aesthetic wars, they have for decades and it's not going to stop. I'm just trying to draw a line at what constitutes appropriate criticism, and this went way over the line.

nextaccountic 4y ago

Is inotify broken? What should be used instead of it to watch for filesystem events?

rwaksmunski 4y ago
I don't know man, I've given up and handed it over to someone more senior. Their port was half the performance and the project was killed. We kept on using FreeBSD for the product.
- nextaccountic 4y ago
  Is it broken regarding to correctness or just performance? I mean, does inotify have some obscure race condition or drop events or duplicate events or something
  - rwaksmunski 4y ago
    > Is it broken regarding to correctness or just performance? Yes. This blog entry explains it much better then I could: https://wingolog.org/archives/2018/05/21/correct-or-inotify-pick-one https://wingolog.org/archives/2018/05/21/correct-or-inotify-...
- Beltalowda 4y ago
  For watching filesystem events FreeBSD's kqueue is much more difficult to use correctly though, and in my experience it certainly doesn't outperform inotify. inotify (and now, fanotify) are specifically designed to watch for filesystem events, whereas kqueue is a generic event system used for many things. In many ways that's better, but it this lack of specialisation also comes with some drawbacks.
  - rwaksmunski 4y ago
    From what I can recall, the performance issues were on the network side. I suspected accept() calls not scaling right, but instrumentation on Linux was quite poor at that time. They had nothing like dtrace back then so I can't be certain.
jgerrish 4y ago
Jesus, is it sad when I hear senior now I don't dream of leading the design of big systems? I think of stakeholder meetings and fighting business requirements? I had an inotify project in process for creating a better developer experience. Seeing this hit Hacker News tells me it's a fucking political landmine. Sigh. Don't worry, I'll have the strength to argue the proper technical solution that still satisfies business needs. That's the important thing!
- nextaccountic 4y ago
  I don't understand what you mean. Anyway I used inotify multiple times in various programming languages and it was always fine, I'm a bit surprised that it's considered "broken" in any way. I mean, is it broken regarding to correctness or just performance?
  - jgerrish 4y ago
    I don't consider it broken, I was referring to political will to build the healthy base of a developer ecosystem. But, you've inspired me to do a deeper historical and technical deep dive of the filesystem event space. Thank you. Have a great weekend!
    - jgerrish 4y ago
      And I do understand. I am one who reached out. Thank you for showing me. They understand who I am. Have a good week!
mastax 4y ago
http://wingolog.org/archives/2018/05/21/correct-or-inotify-pick-one http://wingolog.org/archives/2018/05/21/correct-or-inotify-p...
- nextaccountic 4y ago
  Thanks! Does fanotify fix those issues?
  - scaramanga 4y ago
    Lose events due to inotify buffer overflow, or provide backpressure on entire vfs and allow a watcher to DoS the entire system. Pick one. Similar "minor implementation issues" occur when considering how to fix all of the other "bugs." It's fine if you don't like the design trade-offs of a particular solution. But pretending that they aren't trade-offs, or they aren't valid choices, is just going to leave people shaking their heads at you. Edit: and by "you" i mean the authors of these articles. Although I think Marek is a very talented guy and probably just a bit hyperbolic with his titles.

ajross 4y ago

Was your experience the same thing as the linked article? I mean, reading this as someone who knows epoll and not kqueues quite as much, it sounds very much like "I tried to use this API like something I already know and it didn't work, so I hate it and it's broken". The linked article basically goes through a bunch of scenarios examining clumsy ways to chase a slightly-obscure requirement ("wake up exactly one thread per event using a single descriptor") just to land in the very last paragraph on the clearly correct solution ("just use ONESHOT, that's what it's for!"). I mean, there's literally a feature right there in the man page[1] that does exactly what the author wants. They just didn't want to learn about it and view their ignorance as a bug in the software. Meh. This gets tiresome. As the article linked yesterday points out, epoll() is the "API that powers the internet", and has effectively solved the C10k problem for everyone that has it. But yeah, you need to read the man page. [1] No, seriously, it's right there in the man page, discussing exactly this scenario and how to avoid it.

rwaksmunski 4y ago
I've had to deal with forks and threads, epoll and inotify. It was beyond my skills at the time.
naasking 4y ago
> No, seriously, it's right there in the man page, discussing exactly this scenario and how to avoid it. The point is, do all of the other configurations for epoll have legitimate usecases justifying the complexity and need for those parameters? The kqueue design scales from single-threaded to multithreaded scenarios without issue and without all of these pitfalls, so why not just adopt that design? Why does the specific issue need to be a solution described in the man page at all? > As the article linked yesterday points out, epoll() is the "API that powers the internet", and has effectively solved the C10k problem for everyone that has it. Being able to solve a problem and doing it well are not the same. The latter arguably deserves criticism.
- ajross 4y ago
  > The latter arguably deserves criticism. Ahem. The headline under discussion is "fundamentally broken", which given the context you've granted, sounds closer to a lie than the truth to me. Meh. OS advocates will always have their aesthetic wars, they have for decades and it's not going to stop. I'm just trying to draw a line at what constitutes appropriate criticism, and this went way over the line.