Re: Best practice for accepting TCP connections on multicore?

On 7 June 2014 21:18, Adrian Chadd <adrian@freebsd.org> wrote:

> > 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.
>

Not quite- unless you're dealing with stateless HTTP, you still need to
know what the "current" state of the "current" connection is, which is the
point of that slide.

> 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.

Agreed, but threading models are platform-agnostic.

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.
>

Agreed, but uncontested locking should be virtually cost-free (or close to
that), modern CPUs have plenty of L2/L3 cache to keep enough data nearby,
and there are plenty of cores to keep cycling in the same thread-loop, and
hyper-threading helps with ctx switching (or at least is supposed to). In
any event, shuttling data between RAM and cache (especially with the on-die
RAM controllers, and even if data has to go through QPI/HyperT), and the
cost of changing contexts is tiny compared to that of disk and network IO.

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.

All I can do is to thank you for that, and I hope others join me in doing
so!

-- 
Igor M.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"