Re: debate on 700 threads vs asynchronous code

From: Dan Kegel (
Date: Thu Jan 23 2003 - 21:04:18 EST

Mark Hahn wrote:
>>Nonblocking I/O is totally the way to go if you have full control over your
>>source code and want the maximal performance in userspace. The best way
> why do you think it's better for user-space? I was trying to explain
> it to someone this afternoon, and we couldn't find any reason for
> threads/blocking to be slow. IO-completion wakes up the thread, which
> goes through the scheduler right back to the user's stack-frame,
> even providing the io-completion status. no large cache footprint
> anywhere (at least with a lightweight thread library), no multiplexing
> like for select/poll, etc.

I suspect the thread *does* have a larger cache footprint,
since in nonblocking I/O, session state is stored more compactly.
Also, the threaded approach involves lots more context switches.

> does epoll provide a thunk (callback and state variable) as well as the
> IO completion status?

No. It provides an event record containing a user-defined state pointer
plus the IO readiness status change (different from IO completion status).
But that's what you need; you can do the call yourself.

>>See for an overview of the issue and some links.
> it's a great resource, except that for 700 clients, the difference
> between select, poll, epoll, aio are pretty moot. no?

Depends on how close to maximal performance you need, and whether
you might later need to scale to more clients.

The average server is so lightly loaded, it really doesn't matter which approach you use.
- Dan

Dan Kegel

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:32 EST