4 ms·

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 li

by 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.
  - naasking 4y ago
    > The headline under discussion is "fundamentally broken", which given the context you've granted, sounds closer to a lie than the truth to me. If an abstraction requires a series of special incantations to use correctly, and the other modes of use don't have legitimate use cases of their own, "fundamentally broken" sounds like a fair conclusion.
    - ajross 4y ago
      > a series of special incantations These are the words people use to describe something they don't like but which they don't understand. Really, just read the man page. It's a low level OS facility; these aren't simple APIs (neither is kqueue, FWIW). If you can figure out file descriptor passing or socket options, you can figure out epoll. If you really can't figure out epoll, you probably want to be working at a different layer of the abstraction stack.
      - naasking 4y ago
        No, it's pretty well understood at this point that epoll is worse by comparison. You can see it quite clearly in the number of gotchas and the limitations when compared to kqueue: https://habr.com/en/post/600123/#linux-and-epoll https://habr.com/en/post/600123/#linux-and-epoll
        ajross 4y ago
        Again it amuses me that you've now flipped twice between "worse by comparison / deserving of criticism" and outrageous hyperbole like "fundamentally broken". I can't tell if you want to debate the minutiae of OS synchronization abstractions or just yell at me. I'm happy to do the former if you'll just put the knives away.

by ajross 4y ago

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.
- naasking 4y ago
  > The headline under discussion is "fundamentally broken", which given the context you've granted, sounds closer to a lie than the truth to me. If an abstraction requires a series of special incantations to use correctly, and the other modes of use don't have legitimate use cases of their own, "fundamentally broken" sounds like a fair conclusion.
  - ajross 4y ago
    > a series of special incantations These are the words people use to describe something they don't like but which they don't understand. Really, just read the man page. It's a low level OS facility; these aren't simple APIs (neither is kqueue, FWIW). If you can figure out file descriptor passing or socket options, you can figure out epoll. If you really can't figure out epoll, you probably want to be working at a different layer of the abstraction stack.
    - naasking 4y ago
      No, it's pretty well understood at this point that epoll is worse by comparison. You can see it quite clearly in the number of gotchas and the limitations when compared to kqueue: https://habr.com/en/post/600123/#linux-and-epoll https://habr.com/en/post/600123/#linux-and-epoll
      - ajross 4y ago
        Again it amuses me that you've now flipped twice between "worse by comparison / deserving of criticism" and outrageous hyperbole like "fundamentally broken". I can't tell if you want to debate the minutiae of OS synchronization abstractions or just yell at me. I'm happy to do the former if you'll just put the knives away.