threading

Marko Rauhamaa marko at pacujo.net
Mon Apr 7 10:51:11 EDT 2014


Chris Angelico <rosuav at gmail.com>:

> On Mon, Apr 7, 2014 at 11:49 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Roy Smith <roy at panix.com>:
>> IOW, the processes are there to exercise the CPUs and should not
>> represent individual connections or other dynamic entities.
>
> That's potentially brutal on a shared system! I hope it's controlled
> by an option, or that you do this only in something you're writing for
> yourself alone.

I'm thinking of a dedicated system here and exploiting the available CPU
resources as efficiently as possible.


> There are other reasons for forking per connection, though, such as
> state cleanup.

If we are talking about a handful of connections, a single asyncio
process will be all you need (and will be gentle to other users of the
shared system). When your server has to deal with thousands of
simultaneous connections, spawning a process for each connection is
probably not the optimal approach.

It is precisely the scalability issues that caused Windows and Java go
back to event-driven processing (that was prevalent in GUI design from
the get-go). A company I used to work for was bitten badly by the
multithreaded classic Java I/O, and a NIO overhaul was required when the
connection count went to 500 and beyond.


Marko



More information about the Python-list mailing list