3 ms·

You've spent a lot of effort commenting on this post, and I think you've missed the point entirely. In Jacob's and Ryan's originals, the point wasn't to assert

You've spent a lot of effort commenting on this post, and I think you've missed the point entirely. In Jacob's and Ryan's originals, the point wasn't to assert that preforking is the right way to structure a server -- that's not really the salient issue. (And I'd suspect that these two -- serious Web devs who are familiar with deployment -- probably are well familiar with {epoll, select, kqueue}-based and similar non-blocking, concurrent I/O servers.) The point was that, as Rubyists and Pythonistas and Perl hoo-has, we shouldn't be afraid to delve into POSIX syscalls and take advantage of the wealth of functionality they provide, and that our languages have thin wrappers over those bare syscalls that make it easy to write idiomatic code that utilizes them. The examples were echo servers, for murphy's sake -- are you really worried that we'd have a rash of poorly-thought-through, inefficient echo servers bogging down poor servers across the Internet? They're clearly intended to be simple examples about syscalls not the (yes! very important!) issue of how to handle concurrent connections efficiently.

antonovka 17y ago
And I'd suspect that these two -- serious Web devs who are familiar with deployment -- probably are well familiar with {epoll, select, kqueue}-based and similar non-blocking, concurrent I/O servers.) Given the self-professed low level of familiarity with UNIX systems programming, I don't image that to be the case. The examples were echo servers, for murphy's sake -- are you really worried that we'd have a rash of poorly-thought-through, inefficient echo servers bogging down poor servers across the Internet? They're clearly intended to be simple examples about syscalls not the (yes! very important!) issue of how to handle concurrent connections efficiently. The original post was a strong assertion that fork(2) is correct, and threads are not. The follow-up posts in the 'meme' stretched this idea (with great elation) to fork(2) as a general network concurrency model. This sort of public disinformation does strongly influence future technical decisions.

antonovka 17y ago

And I'd suspect that these two -- serious Web devs who are familiar with deployment -- probably are well familiar with {epoll, select, kqueue}-based and similar non-blocking, concurrent I/O servers.) Given the self-professed low level of familiarity with UNIX systems programming, I don't image that to be the case. The examples were echo servers, for murphy's sake -- are you really worried that we'd have a rash of poorly-thought-through, inefficient echo servers bogging down poor servers across the Internet? They're clearly intended to be simple examples about syscalls not the (yes! very important!) issue of how to handle concurrent connections efficiently. The original post was a strong assertion that fork(2) is correct, and threads are not. The follow-up posts in the 'meme' stretched this idea (with great elation) to fork(2) as a general network concurrency model. This sort of public disinformation does strongly influence future technical decisions.