Re: So, Poll is not scalable... what to do?

Davide Libenzi
2003-11-13T00:33:46Z

On 12 Nov 2003, bill davidsen wrote:

> In article <20031112053207.GA9634@alpha.home.local>,
> Willy Tarreau <willy@w.ods.org> wrote:
> | On Tue, Nov 11, 2003 at 05:52:42PM -0600, kirk bae wrote:
> | > If poll is not scalable, which method should I use when writing
> | > multithreaded socket server?
> |
> | Honnestly, if you're using threads (I mean lots of threads, such as one
> | per connection), I don't think that poll performance will be your worst
> | ennemy. The first thing to do is to handle the task switching yourself
> | either with a publicly available coroutine library or with one of your own.
>
> It's not clear that with 2.6 this is necessary or desirable. I'll let
> someone who worked on the new thread and/or futex development say more
> if they will, but I'm reasonable convinced that in most cases the kernel
> will do it better.

Pros & Cons:

*) Coroutines cost is basically its stack (8-16Kb). Threads there's a
little bit more under the hood

*) No locks at all with coroutines

*) Coroutine context switch time was about 20 times faster last time I
tried. I used this:

http://www.xmailserver.org/libpcl.html

against O(1)

*) Coroutines require a more careful coding then threads, expecially
stackwise

*) Achieving SMP scalability/balancing with coroutines is not trivial
while with threads it comes along (well, almost)

Coroutines are not the only alternative though. I/O driven state machines
can make you save some stack space at expenses of less trivial coding.

- Davide