... one of the arguments the event folks sometimes throw against the thread folks is that the thread folks have a stack per thread. And if you've got a thread per connection then you're paying a stack per connection. That can be expensive if your stack is really deep. Whereas with the event model you only have one stack.

It's a good point. The counterpoint is that in the event model, much of the state which the thread folks store on the stack is stored on the heap, in a different form. And because languages such as C are designed more for the threaded/linear programming model, there are few optimizations to help the event folks. For example, in thread land you'd write code:

       int foo()
       {
           int local1;
           int local2;
           ...
           do_some_io();
           ...
       }

in event land you might write:

       struct foo_data {
           int local1;
           int local2;
           ...
       };

       void foo_after_io_completes(void *arg)
       {
           struct foo_data *locals = arg;
           ...
       }

       void foo()
       {
           struct foo_data *locals = malloc(sizeof(struct foo_data));
           ...
           initiate_io(foo_after_io_completes, locals);
       }

But in the thread version, some of those locals may actually never be allocated. They may live only in registers. But the compiler can't perform that optimization in the event model. These sort of micro details are what make me question how good the event model really is for the average programmer who doesn't want to think about cycles all the time. That's what compilers are supposed to help with.