Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Explain “Event-Driven” Web Servers to Your Grandma

daverecycles.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Explain “Event-Driven” Web Servers to Your Grandma

#31

Post by jerf »

wmf wrote: post #26
jerf wrote: post #23

Earlier quoted context omitted.

"Now, be fair: Erlang papers over the deficiencies of the lower layers (namely, the kernel) with significant manual effort." Since the various Xpolls were added to the kernel, I would disagree. Even based on a select loop the kernel has still been happy to do many things asynchronously for a long time now, it's just a bit of a klunky API. What stopped it from being easy was that C had no good concurrency story except…

the OS doesn't mind threadlets/green threads/OS processes Except for the blocking system calls and blocking page faults that block all your green threads.

To the extent those can be papered over, they have been by most good runtimes; the remainder is evenly applied to all languages and runtimes under discussion because nobody can escape from them at all, no matter how awesome the top layers are.

This is what I was referencing when I offhandedly mentioned the fact that some layers can make papering over them actually impossible; if the kernel can not be convinced to do it with any series of syscalls, or worse yet the hardware itself can not be convinced, you lose, game over. Another example, Haskell's very strong type system can do a fairly good job of making really damned sure you don't escape from the system, which is useful for making an STM that is actually usable precisely because the smallest escape hatch tends to bring it down. But the downside is that a library or something can actually make it impossible to hack around a problem (with any reasonable degree of effort).

Re: Explain “Event-Driven” Web Servers to Your Grandma

#32

Post by sophacles »

What a terrible analogy. I mean, there is a pizza-shop or other food service analogy in there, I've made it plenty of times. The problem is that when you make the phone call = request in the analogy, you make the phone connection analogous to the socket. At least have the operator put the caller on hold!

Of course then Grandma, not being an idiot, will say "why not just have driver bring the pizza and not have the phone all tied up to begin with?" and she is absolutely correct. It is better to just set up a scenario where you have waiters, and customers show up a the shop, and in blocking your waiter doubles as the cook, so you need one waiter per meal... and so on. This analogy passes a slightly closer examination.

Re: Explain “Event-Driven” Web Servers to Your Grandma

#33

Post by jlew »

While a great attempt at an analogy, I don't think that it really helps things. I've never misunderstood THAT part of event-based asynchronicity (is that even a word?) The part that is confusing to me is HOW it works and eventually to the point of WHY and/or HOW it is supposedly better than traditional threading (other than cleaner-looking code). I've never seen a good explanation in non-OS programmer terms.

To me, it seems that no matter how you take the "messages" to do work, that work still has to be done. It surely doesn't magically use less resources because you told the OS that it could just call you back when it is done, as opposed to you having to hang around? Something has to be hanging around on one side or the other, and the "call back" takes resources as well, surely? It seems that you are just trading tit for tat. Maybe the reason is to not utilize some specific resource in the meantime?

Re: Explain “Event-Driven” Web Servers to Your Grandma

#35

Post by gruseom »

sedachv wrote: post #24
amalcon wrote: post #21

Earlier quoted context omitted.

Pick something like Erlang and the problem never exists in the first place. You don't have to paper over the deficiencies in the lower levels, because the levels below the code you're writing aren't deficient for concurrency in the first place. Now, be fair: Erlang papers over the deficiencies of the lower layers (namely, the kernel) with significant manual effort. It's just that someone else has already gone to this…

"Now, be fair: Erlang papers over the deficiencies of the lower layers (namely, the kernel) with significant manual effort. It's just that someone else has already gone to this effort. BEAM is an event-based server behind the scenes, with lots of syntactic sugar to make it look multithreaded. The PLT Scheme webserver is another example of this." This really is not a valid critique. When you get down to it, I/O is goi…

all that it's doing for you is just thinly "papering over" the syscalls

But wasn't that the whole point of Node - to expose the lower layer of nonblockingness while still allowing a high level language for everything else?

If you really want to see a well-done papering over, take a look at Gambit Scheme, instead of BEAM

That's interesting. What are the distinctive points that make it good?

Re: Explain “Event-Driven” Web Servers to Your Grandma

#36

Post by jasonkester »

Terrible analogy, especially when there exists a better one within the food service industry. How about rewriting that article from the perspective of a coffee shop?

We've all been to the neighborhood coffee place where the girl will take your order, turn around and make your entire drink, hand it to you and ask for payment. We've all stood in that line.

We've also all been to Starbucks, where the girl takes your order, writes it on a cup, takes your money, then moves on to the next customer. And by the time you walk to the other end of the counter the guy in front of you already has coffee in his hand.

It still doesn't fit web servers exactly, but at least it fits the real world.

Re: Explain “Event-Driven” Web Servers to Your Grandma

#37

Post by sedachv »

gruseom wrote: post #35
sedachv wrote: post #24

Earlier quoted context omitted.

"Now, be fair: Erlang papers over the deficiencies of the lower layers (namely, the kernel) with significant manual effort. It's just that someone else has already gone to this effort. BEAM is an event-based server behind the scenes, with lots of syntactic sugar to make it look multithreaded. The PLT Scheme webserver is another example of this." This really is not a valid critique. When you get down to it, I/O is goi…

all that it's doing for you is just thinly "papering over" the syscalls But wasn't that the whole point of Node - to expose the lower layer of nonblockingness while still allowing a high level language for everything else? If you really want to see a well-done papering over, take a look at Gambit Scheme, instead of BEAM That's interesting. What are the distinctive points that make it good?

Erlang has a very simple runtime model - processes basically don't have a stack across invocations (message receives) or a dynamic environment, the only concurrency is in mailboxes, and despite claims of being "soft real-time" there's actually not a lot you can do to influence scheduling policy.

Gambit supports pre-emptive multitasking for green threads, with continuations, exceptions, dynamic-wind, and (optionally inheritable) dynamic environments.

Gambit provides mailboxes, but also locks and condition-variables (with a much richer API than most implementations; usually CVs wake either one or all threads, Gambit has functions for both).

Gambit also has a pretty good story for controlling thread scheduling and task deadlines (see SRFI-21: http://srfi.schemers.org/srfi-21/srfi-21.html).

The manual describes these things pretty well:

http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Thread...

Post reply on HN