In article <468D0847.8090608@netbsd.org>,
Darren Reed  <darrenr@netbsd.org> wrote:
>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?
>
>I dislike this approach becaues it is a new way to create a socket.
>
>Currently you create a socket with socket(), have the system allocate
>you a new one with accept() and...I think that is the limit.
>
>I would rather see something like:
>
>setsockopt(fd, SOL_SOCKET, SO_TEMPLATE,  &template, sizeof(template))
>
>The next question is then how to define the "template" data structure
>in such a way that it is extensible for arbitrary sockets.
>
>Another reason that I prefer this approach because it is easier to
>learn or adapt to use.  Also when reading new code, someone is
>confronted with a "wtf is this socket option" rather than "wtf is
>this socketfrom" and goes looking for socketfrom() in your app because
>it isn't a widely known system call.

You can pass the template socket fd in as the template :-)

christos