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

[Yuya Nishihara]

On Fri, 13 May 2016 18:04:33 +0100, Jun Wu wrote:
> 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.

Sorry for unclear words. I meant I didn't see a reason to make PreforkMixIn
a mix-in of SocketServer. PreforkMixIn does its own job alone except for a
trivial things, bind() and listen().

> 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

In this version, MasterServer replaces serve_forever() completely and doesn't
use most of the features provided by SocketServer. That reminds me of a CSocket
story. [1]

 [1]: https://tangentsoft.net/wskfaq/articles/csocket.html

> 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 try to express why I feel your PreforkMixIn and the other SocketServer stuffs
are black magic.

 - the order of bind(), listen(), fork(), accept(), _exit(), etc. is important,
   which is controlled solely by BaseServer (and its derived class, TCPServer.)
 - sometimes it doesn't fit to our needs, so we have to override methods and
   call super(), which makes hard to track what's going on.
 - and the problem is getting worse if there are more than one mix-ins that
   override the same method. the order is controlled by how classes are listed.
 - so I think mixin isn't a good way to build a server of different models.

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

at the cost of making a mix-in class perfectly fit to SocketServer.

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

I care about the complexity of SocketServer utterly unnecessary for our
commandserver. There are two choices, and I prefer (b) because it's good time
to get rid of SocketServer.

 a) backport and maintain SocketServer until we can drop support for Python 2.x
 b) replace SocketServer by simpler one and eliminate glue codes

(a) sounds like "forever" to me.