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

[Jun Wu]

On 05/11/2016 01:17 PM, Yuya Nishihara wrote:
> As I said before on IRC, I'm -1 for the backport. I'd rather resurrect a
> simple socket server replacement only for commandserver.
>
> Reasons:
>
> It isn't difficult to write a simple fork-per-request server. I wouldn't
> switch to SocketServer if I knew it is broken when I wrote the patch of
> 'unix' mode service, 840be5ca03e1.

As I said in the commit message, my intension is to have this until we can
use Python's socketserver directly, which would save some lines eventually.

So I care about API compatibility with stdlib, and that's the main reason
to do the backport instead of reinventing the wheel.

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? If so, I can try implement a lightweight select/poll
based forking server.

If the size of socketserver.py is a concern, I can remove the unnecessary
parts so it would become smaller.

>> Consider the facts that:
>>
>> - We need to support Python 2.6 now
>> - There are other users of SocketServer: commandserver, hgweb. hgweb can be
>>   affected by the Python 2.6 race condition if it uses the forking model.
>>   It is okay to re-invent the logic for chgserver alone but supporting all
>>   existing code is more complex and does not worth the efforts imo.
>
> hgweb.server falls back to ForkingMixIn only if Python is compiled without
> threading. I guess almost all users would use ThreadingMixIn.

I don't really care about hgweb either. Let's forget about it.

>> - There seems to be no existing solid, lightweight alternative to SocketServer.
>> - The Python 3.5 socketserver module looks good enough on performance and
>>   feature set. We don't gain much re-inventing it and we may fall behind stdlib
>>   in the long run.
>>
>> It seems reasonable although suboptimal to do a backport now. This backport and
>> its following changes will maintain API compatibility with Python's standard
>> socketserver. Eventually when we only need to support Python >= 3.5, we can
>> easily remove this file and just use Python's.
>
> I expect chg will be switched to pre-forking server (or replaced by something
> better than chg) when we're ready to drop Python 2.x compatibility.

I think SocketServer won't make that harder, is it?