Optimal multithread model

Brandon Black blblack at gmail.com
Tue Mar 16 15:46:10 CET 2010


On Tue, Mar 16, 2010 at 8:40 AM, Christophe Meessen
<christophe at meessen.net> wrote:
> Regarding the threads vs. processes discussion I see a use case which hasn't
> been discussed yet.
>
> Consider the C10K application with many cold links and a context (i.e.
> authentication, data structures, ...) associated to each connection.
>
> With threads we can easily set up a pool of worker threads that easily and
> efficiently pick up the context associated to the connection becoming
> active. I don't see how an equivalent model can be efficiently implemented
> with processes.
>
> I would prefer it was possible to do it with processes because they have the
> benefit of a separate  memory space which is much better for security and
> robustness. But I couldn't find a way to do it as easily and efficiently as
> with threads.
>

You're again mixing up "how do I scale on many cores" with "how do I
scale for many slow network events on one core", which can be combined
into the "how do I scale for many slow network events on many cores".
You would never solve the combined problem with blocking processes
alone.  The process model for this would be one process per core, and
either many threads per process (one for each connection that process
is handling), or an event loop per process handling the many
connections.  The thing we all seem to agree on is that eventloops
beat threads within one process, but the thing we disagree on is
whether it's better to have the top-level processes be processes or
threads.



More information about the libev mailing list