4 ms·

That is true in some sense. Yet, on the other hand, the first versions of Linux were written without consulting the extensive literature (which was all about m

by catzaa 17y ago

That is true in some sense. Yet, on the other hand, the first versions of Linux were written without consulting the extensive literature (which was all about microkernels) [1]. As another example – a guy studying with me made his own circuit boards (had his own acid production line project going on in his dorm room). You would never use such a circuit board in any professional setting. Yet he learned a lot about other stuff with his electronics projects. Sometimes the goal of learning isn’t really implementing something directly. As an example, a recursive function isn’t really the best way to calculate Fibonacci numbers. If someone wants to learn about forking by writing a simple web-server thingy then it may be a good idea? Most of these projects were probably done in their free time. Who would be the better programmer – the guy that wrote this, or the guy that knocked back a beer and sat in front of the TV? [1] I am not an operating system expert, but this is at least the impression I got after reading the flame-wars email.

antonovka 17y ago
Yet, on the other hand, the first versions of Linux were written without consulting the extensive literature (which was all about microkernels) [1]. In the early 90s nearly all of the operating system research was going into Microkernels, but there was already 30+ years of standing research to borrow from (and Linux very much did -- the fact that it's similar enough to run the same software as Solaris and BSD systems is not due to spontaneous re-invention). Despite the fact that Linux and the BSDs did not adopt the microkernel architecture -- and pure microkernels, for most purposes, died out -- quite a bit of value did come from that research, such as the Mach VM system, which was then borrowed by 4.4BSD operating systems and others. Most of these projects were probably done in their free time. Who would be the better programmer – the guy that wrote this, or the guy that knocked back a beer and sat in front of the TV? Rather than taking an incredibly assertive but misguided blog post at face value (and propagating it further), what is wrong about reading the widely available, easily discovered literature and implementing an event-based/event+thread-based implementation instead?
- Scriptor 17y ago
  What's a good first step to finding this literature?
  - antonovka 17y ago
    In this case -- start by picking something you know to scale well, and find out how it does it. For instance, if you're familiar with nginx through web development, you'd find this on the nginx web page: "Architecture and scalability:" * kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), event ports (Solaris 10), select, and poll support; Once you've narrowed your search, start looking for well-respected books on the subject -- there's a long list of them in the thread below.
- paulsmith 17y ago
  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.

by catzaa 17y ago

antonovka 17y ago

Yet, on the other hand, the first versions of Linux were written without consulting the extensive literature (which was all about microkernels) [1]. In the early 90s nearly all of the operating system research was going into Microkernels, but there was already 30+ years of standing research to borrow from (and Linux very much did -- the fact that it's similar enough to run the same software as Solaris and BSD systems is not due to spontaneous re-invention). Despite the fact that Linux and the BSDs did not adopt the microkernel architecture -- and pure microkernels, for most purposes, died out -- quite a bit of value did come from that research, such as the Mach VM system, which was then borrowed by 4.4BSD operating systems and others. Most of these projects were probably done in their free time. Who would be the better programmer – the guy that wrote this, or the guy that knocked back a beer and sat in front of the TV? Rather than taking an incredibly assertive but misguided blog post at face value (and propagating it further), what is wrong about reading the widely available, easily discovered literature and implementing an event-based/event+thread-based implementation instead?

Scriptor 17y ago
What's a good first step to finding this literature?
- antonovka 17y ago
  In this case -- start by picking something you know to scale well, and find out how it does it. For instance, if you're familiar with nginx through web development, you'd find this on the nginx web page: "Architecture and scalability:" * kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), event ports (Solaris 10), select, and poll support; Once you've narrowed your search, start looking for well-respected books on the subject -- there's a long list of them in the thread below.
paulsmith 17y ago
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.