3 ms·
This is only true if you think your application can do a better job of scheduling than the underlying OS kernel. In many (if not most) cases, this is false. Wh
by neilc 18y ago
This is only true if you think your application can do a better job of scheduling than the underlying OS kernel. In many (if not most) cases, this is false.
Why is it false? As the other reply notes, you have more domain knowledge than the kernel's scheduler does. You also didn't need to pay the overhead of entering the kernel to context switch (which is why context switches between userspace threads are cheaper than between kernel threads). In the case of fork()-based servers, you also need to flush the TLB (depending on the CPU architecture).
I'd be curious to see links that support your last claim: AFAIK, it is fairly well-known that event-based daemons using epoll/kqueue are the most performant technique for writing scalable network servers. See C10K, etc.
- rcoder 18y agoThe problem is that, in the real world, monolithic polling network servers have to manage all the transaction-specific context for your application in a single binary. I'm not challenging the fact that the C10K architecture wins if we're talking about static content. Real webapps don't live and die by their static content performance, though: the critical path is through the dynamic content generation, which means that select()/poll()/et. al. don't buy you much, unless you can hook your database client events and application thread scheduling inside that loop as well. Green (a.k.a. userspace) threads are one good solution, but fork() isn't the performance-killer that people seem to think it is, either.