Supporting already opened sockets in our socket-based server classes

Hello What about allowing all our socket servers -- from SocketServer to WSGIServer, to run with an existing socket. The use case is to make it easier to write applications that use the pre-fork model to run several processes against the same socket. Basically: - the main process creates a socket, binds it and listen to it - the main process forks some subprocesses and pass them the socket fd value - each subprocess recreates a socket object using socket.fromfd() -- so it does not bind it - each subprocess can accept() connection on the socket I have a working prototype here : https://github.com/tarekziade/chaussette/blob/master/chaussette/server.py (don't look at the code I made it quickly just as a proof of concept) What I am proposing is the following syntax: if the host passed to the class is of the form: fd://12 The class will try to create a socket object against the file descriptor 12, and will not bind() it neither accept() it. How does that sounds ? If people like the idea I can try to build a patch for 3.x, and I can certainly release a backport for 2.x Cheers Tarek

Le 06/06/2012 09:56, Tarek Ziadé a écrit :
Passing a pseudo-URL where a host name is expected sounds like a bad idea. Also, I don't understand the "neither accept() it" part. Surely you need to accept() incoming connections, so perhaps you mean "neither listen() it"? (also, I'm not sure calling listen() another time is a problem) Regards Antoine.

On 6/6/12 2:28 PM, Antoine Pitrou wrote:
Well, unix sockets are using this convention to point paths to unix sockets. e.g. unix:///some/path in general, theURI scheme seems widely used out there, https://en.wikipedia.org/wiki/URI_scheme What do you propose ? another option ?
Yeah that was a typo -- I do listen() before I fork
(also, I'm not sure calling listen() another time is a problem)
I don't think so, but the usual pattern I have seen is to call listen() before the forking

Le 06/06/2012 17:23, Tarek Ziadé a écrit :
Which unix sockets? In socketserver?
in general, theURI scheme seems widely used out there,
My point is that if the parameter is currently a hostname, it isn't a URI (AFAIK). Starting to mix both concepts could quickly become confusing.
What do you propose ? another option ?
I think that's better indeed. Regards Antoine.

On Wed, 06 Jun 2012 17:23:15 +0200 Tarek Ziadé <tarek@ziade.org> wrote:
I think what you're trying to achieve has merit, but you're doing it in the wrong place. Using a URL-like string instead of a host name? Really? So how about a new subclass, "PreForkedTCPServer", that takes the file descriptor instead of the host/port pair when created? You'd probably want to tweak the class tree somewhat, but that seems like a more palatable API for what you're trying to do. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Le 06/06/2012 09:56, Tarek Ziadé a écrit :
Passing a pseudo-URL where a host name is expected sounds like a bad idea. Also, I don't understand the "neither accept() it" part. Surely you need to accept() incoming connections, so perhaps you mean "neither listen() it"? (also, I'm not sure calling listen() another time is a problem) Regards Antoine.

On 6/6/12 2:28 PM, Antoine Pitrou wrote:
Well, unix sockets are using this convention to point paths to unix sockets. e.g. unix:///some/path in general, theURI scheme seems widely used out there, https://en.wikipedia.org/wiki/URI_scheme What do you propose ? another option ?
Yeah that was a typo -- I do listen() before I fork
(also, I'm not sure calling listen() another time is a problem)
I don't think so, but the usual pattern I have seen is to call listen() before the forking

Le 06/06/2012 17:23, Tarek Ziadé a écrit :
Which unix sockets? In socketserver?
in general, theURI scheme seems widely used out there,
My point is that if the parameter is currently a hostname, it isn't a URI (AFAIK). Starting to mix both concepts could quickly become confusing.
What do you propose ? another option ?
I think that's better indeed. Regards Antoine.

On Wed, 06 Jun 2012 17:23:15 +0200 Tarek Ziadé <tarek@ziade.org> wrote:
I think what you're trying to achieve has merit, but you're doing it in the wrong place. Using a URL-like string instead of a host name? Really? So how about a new subclass, "PreForkedTCPServer", that takes the file descriptor instead of the host/port pair when created? You'd probably want to tweak the class tree somewhat, but that seems like a more palatable API for what you're trying to do. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
participants (3)
-
Antoine Pitrou
-
Mike Meyer
-
Tarek Ziadé