Re: debate on 700 threads vs asynchronous code

[Dan Kegel <dkegel@ixiacom.com>]

Lee Chin wrote:
 > Terje Eggestad <terje.eggestad@scali.com> wrote:
 >> Apart from the argument already given on other replies, you should
 >> keep in mind that you probably need to give priority to doing receive.
 >> THat include your clients, but if you don't you run into the risk of
 >> significantly limiting your bandwidth since the send queues around your
 >> system fill up.
 >>
 >> Try doing that with threads.
 >>
 >> Actually I would recommend the approach c)
 >>
 >> c)  Write an asynchronous system with only 2 or three threads where I
 >> manage the connections and keep the state of each connection in a data
 >> structure.
 >
> Today I do method (C)... but many people seem to say that, hey, pthreads does almost
> just that with a constant memory overhead of remembering the stack per blocking
> thread... so there is no time difference, just that pthreads consumes slightly more
> memory.  That is the issue I am trying to get my head around.

The best way to get your head around it is to
benchmark both approaches, and spend some time
refining your implementation of each so you
understand where the bottlenecks are.

> That particular question, no one has answered... in Linux, the scheduler will not go 
> around crazy trying to schedule prcosses that are all waiting on IO.  NOw the only 
> time I see a degrade in threads would be if all are runnable.... in that case a async
> scheme with two threads would let each task run to completion, not thrashing the
> kernel.  Is that correct to say?

There are lots of other issues, too.
Talk is cheap and fun, but only coding will give the real answer.
Go forth and code...

- Dan