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

[Jun Wu]

On 05/12/2016 12:02 AM, Yuya Nishihara wrote:
>> I think SocketServer won't make that harder, is it?
>
> Yeah, I guess it will be harder to write a PreForkingMixIn since IMHO
> pre-forking works very differently from fork-per-request or
> thread-per-request.
>
> That's why I don't care for the SocketServer compatibility.

I tried to implement the preforking model in a quick and dirty way, and got this:

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

which does not look bad and socketserver does save a lot lines here.
Most of the lines are necessary to implement a preforked server anyway.

(I haven't tried to convert them into MixIns but it's at least possible
for the master).

On 05/12/2016 02:53 PM, Yuya Nishihara wrote:
> On Wed, 11 May 2016 16:17:08 +0100, Jun Wu wrote:
>> I think we may benefit from Python 3 stdlib. For example, the "selectors"
>> module makes it easy to switch to epoll/kqueue if we want to. Do you think
>> we will never use them?
>
> I don't see much benefit to use epoll/kqueue. Our code is mostly
> synchronous, fewer socket events + long synchronous operation in worker
> process.

That's true. This is however not a strong reason to use it.

>> If so, I can try implement a lightweight select/poll based forking
>> server.
>
> Can you wait a week or two? I want to try if I can salvage (and fix bugs
> of) the fork-per-request server from chg repository. I've written both
> pre-forking and fork-per-request servers for chg.

I still prefer stdlib mainly because I think the common practice is to stick to
stdlib unless it very broken. In the case the socketserver from Python 3 is not
broken and does help simplify code and relief our maintenance burden.