Subject: Re: Proposal: socketfrom()
To: None <tls@rek.tjls.com>
From: Simon Burge <simonb@NetBSD.org>
List: tech-net
Date: 07/05/2007 16:27:53
Thor Lancelot Simon wrote:

> I have an application that makes outbound TCP connections at a very high
> rate, so high that the overhead of additional system calls to set socket
> options considerably impacts performance.
> 
> I could partially address this by adding a system call that sets multiple
> socket options at once (which, I think, would be a better API than
> setsockopt() anyway) but that gets rid of _all but one_ system call to
> set up the socket before connect(); I want to get rid of them all.
> 
> I'd like to make it possible to set options on one "template" or "master"
> socket and then have them inherited by children, as listen()/accept() make
> possible for the other direction.  I'm thinking of something along the lines
> of this:
> 
> int socketfrom(int template, int domain, int type, int protocol);
> 
> Which would return a new socket using the socket options already set on
> socket "template".  If domain, type, and protocol don't match, this is
> an error (or perhaps it would be best to omit them entirely and just
> have one argument, the template socket.
> 
> Opinions?

My initial thoughts are that this is a special case system call that
would be there to speed up one application and wouldn't have much use
in general, and that we'd open the floodgates to keep on adding system
calls for the next performance problem and so on.

Is there any prior art for this sort of thing?  Googling for
"socketfrom" didn't return anything useful.

Cheers,
Simon.