Scott Ferguson on epolling: just use threads

From the Resin interest mailing list:

On Dec 26, 2006, at 9:59 AM, Serge Knystautas wrote:

> Steve Z wrote:
>> Hi
>> Sun JRE nio has supported epoll from JDK5.0_up9,JDK6.0 at
>> bottom, I wanna know whether it meaned resin support epoll now?
>> thanks.
> Resin does not use nio, so how the Sun JVM implements NIO is not
> significant.
> This is an interesting read on the matter from when epoll was a new
> feature:
> thread_id=26700

Yep. Threads aren't all that bad, especially on recent operating
systems. Remember, that any epoll/nio solution has extra overhead
associated with detaching/attaching the thread.

A poll/epoll is essentially the same as an operating system block,
but handled at the user level (and so requires several extra system
calls). OS blocks essentially do the exact same thing, but are
handled by the kernel, which is far more efficient.

The problem at the moment is really 32-bit memory limitations. Since
threads take up virtual memory, lots of threads take up lots of
memory. In a 64-bit system, that's not an issue. But we're running
up to the limits of 32-bit virtual memory with lots of threads.

That issue will go away in the next 3-5 years as we transition to 64-
bits. At that point, it would make sense to just stick with lots of
threads and avoid the epoll issue entirely.

No comments: