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

Yuya Nishihara yuya at tcha.org
Wed May 11 19:02:46 EDT 2016


On Wed, 11 May 2016 16:17:08 +0100, Jun Wu wrote:
> 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.

[snip]

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

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.


More information about the Mercurial-devel mailing list