[PATCH 1 of 6] socketserver: backport a less sucky socketserver from python 3.5.1

Jun Wu quark at fb.com
Fri May 13 13:04:33 EDT 2016


On 05/13/2016 03:27 PM, Yuya Nishihara wrote:
> It looks like a black magic to me. "Why isn't PreforkMixIn a stand-alone class?
> because it needs TCPServer.__init__(). But why? in order to call bind() and
> listen(). Then, why not do that by PreforkMixIn, blah blah...

I don't quite understand this. Using the name *MixIn is because it fits with
others (ForkingMixIn) and we do reuse code.

The first version of the gist has the non-mixin version: 2 classes for
master and worker:

https://gist.github.com/quark-zju/015c448b548bc6fbad4105868e2028ac/b8e1d0f80ca49d3161222b0c52d09c73492d488e

I don't feel it's that black since the master does __init__ (bind) to get
the fd and the workers do server_forever (listen + accept), which is very
clear to me.

> Well, perhaps I really hate the SocketServer design because it complicates
> things in my sense.
>
>> I still prefer stdlib mainly because I think the common practice is to stick
>> to stdlib unless it very broken.
>
> I generally agree with you, but how many features will SocketServer give us?
>
> With your PreforkMixIn, SocketServer will just do the initialization of socket
> object and run a trivial main loop. Plus, it will bring us IMHO complicated
> class hierarchy we sometimes have to care for the order of inheritance.

I think we actually benefit from the seemingly useless class hierarchy. Because
when we have some config option like:

   [chgserver]
   servermodel = prefork
   servermodel = fork

It's just a few lines to switch between them.

And it's stdlib anyway so you don't care about the size. I'm sure there are
other stdlib modules being unnecessarily big.



More information about the Mercurial-devel mailing list