Best practice for accepting TCP connections on multicore?

[Adrian Chadd]

> Not quite - the gist (and the point) of that slide with Rob's story was that
> by the time Rob wrote something that could comprehensively deal with states
> in an even-driven server, he ended up essentially re-inventing the wheel.

I read the same slides you did. He didn't reinvent the wheel - threads
are a different concept - at any point the state can change and you
switch to a new thread. Event driven, asynchronous programming isn't
quite like that.

> The undeniable truth of the current state of CPU architecture is that while
> the GHz remains the same (and in a lot of cases is actually going down), the
> number of cores is on the increase, so it makes little sense to have a
> server that doesn't take full advantage of all available resources.

Agreed.

> Paul Tyma's presentation posted earlier did conclude with various models for
> different types of daemons, which the OP might find at least interesting.

Agreed, but again - it's all java, it's all linux, and it's 2008.

>
>> We can do better.
>
>
> <snip>
>
> Quite likely- but the OP was asking what the current state is, and not what
> could happen X years down the line.

The current state is that threads and thread context switching are
more expensive than you'd like. You really want to (a) avoid locking
at all, (b) keep the CPU hot with cached data, and (c) keep it from
changing contexts.

It's cool man, I'm actually hacking on this shit to push things
forward. For fun. Because hey, if noone is going to pay me to do it
for real, I may as well get some pleasure out of it.


-a