4 ms·

I think it's basically just the equivalent of select(2)? Once upon a time, all network servers were written this way. They were pretty fast, too.

• icedchai 6y ago
  Most select(2) based servers were single threaded, however. Not that this is necessarily a bad thing.
  • cgh 6y ago
    Yes, you are right, of course. I shamefully misread the article. It's closer to listen/accept/fork.
    • pdonis 6y ago
      > It's closer to listen/accept/fork. No, it isn't, it's doing the same thing as a select(2) server would do, except it's using epoll to avoid scaling issues when you have a lot of file descriptors in the polling set. The only difference is that the workers are doing something that requires CPU, not I/O, so OS threads are being used for them (a single threaded server would be fine if the workers were just doing more I/O, like sending a request to a remote database and waiting for a response). But the worker threads are not doing any I/O management at all; they read from or write to an fd only when the central server that is calling epoll tells them to. In the listen/accept/fork model, the central server forgets about an fd once it has passed it to a handler process, and the handler process using blocking I/O.
• kragen 6y ago
  When was this time? In BSD, which introduced select(2), most network servers ran from inetd. I got a stern talking-to from the computer security folks for running a process in my .cshrc that would repeatedly finger someone at another university, where their fingerd ran from inetd, because I was making their shared VAX run unacceptably slowly. Early versions of httpd included instructions on how to run it from inetd, along with a note that you would probably regret it. Are you thinking of, like, CICS systems from the 1970s connected to SNA or something? I mean they didn't have select(2) but they did serve many clients in a single process.
  • icedchai 6y ago
    Long running network servers, such as most IRC servers, were written using select. Example: https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_daemons https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_C...
    • kragen 6y ago
      IRC servers were indeed written using select(2), because interaction between the clients is the whole point of IRC; that gets a great deal more difficult if you spawn off a separate process for each client! I think ICB/FNet predates IRC slightly and was also written using select(2). But IRC wasn't written until 1988, at which point select(2) and inetd were already about ten years old, and things like (most) FTP servers continued to run one process per concurrent client throughout the 1990s. (Walnut Creek CDROM wrote their own high-performance event-driven FTP server, IIRC.) Typically on the machine where you were running the IRC server you would also be running about a dozen or two other servers from inetd, all written with the one-process-per-client model. If there was a time when all network servers were written using select(2) or similar event-driven APIs, it wasn't 1988 or later.
      • icedchai 6y ago
        I think the previous poster was just exaggerating... "All" network servers is a pretty broad category. They were never all written using select.
        • kragen 6y ago
          They were never mostly written using select, either.
          • icedchai 6y ago
            you are correct. I'm not the original poster though.