client-server parallellised number crunching

Chris Angelico rosuav at gmail.com
Wed Apr 27 16:58:22 CEST 2011


On Thu, Apr 28, 2011 at 12:15 AM, Hans Georg Schaathun <hg at schaathun.net> wrote:
> Quite.  I was referring to some tutorials and documentation recommending
> to use non-blocking sockets and select() within a single thread.  I
> cannot say that I understand why, but I can imagine the benefit with
> heavy traffic.

Others will doubtless correct me if I'm wrong, but as I see it, select
is the better option if your code is mostly stateless, while threading
is easier if you want to maintain state and processing order. For
instance, with my MUD, I have one thread dedicated to each client; if
the client sends a series of commands, they will automatically queue
and be processed sequentially. On the other hand, if you run a server
where all connections are identical, it's easier to use select() and a
single thread; every time select returns, you process whichever
sockets can be processed, and move on. I don't know if the
considerations become different when you have insane numbers of
simultaneous connections; how well does your process cope with ten
thousand threads? a couple of million? In Python, it'll probably end
up pretty similar; chances are you won't be taking much advantage of
multiple CPUs/cores (because the threads will all be waiting for
socket read, or the single thread will mostly be waiting in select()),
so it's mainly a resource usage issue. Probably worth testing with
your actual code.

Chris Angelico



More information about the Python-list mailing list