On Mar 1, 2012, at 17:10, William Herrin <b...@herrin.us> wrote: > If took you 50 lines of code to do > 'socket=connect("www.google.com",80,TCP);' and you still managed to > produce a version which, due to the timeout on dead addresses, is > worthless for any kind of interactive program like a web browser. And > because that code isn't found in a system library, every single > application programmer has to write it all over again. > > I'm a fan of Rube Goldberg machines but that was ridiculous.
I'm thinking for this to work it would have to be 2 separate calls: Call 1 being to the resolver (using lwres, system resolver, or whatever you want to use) and returning an array of struct addrinfo- same as gai does currently. If applications need TTL/SRV/$NEWRR awareness it would be implemented here. Call 2 would be a "happy eyeballs" connect syscall (mconnect? In the spirit of sendmmsg) which accepts an array of struct addrinfo and returns an fd. In the case of O_NONBLOCK it would return a dummy fd (as non-blocking connects do currently) then once one of the connections finishes handshake the kernel connects it to the FD and signals writable to trigger select/poll/epoll. This allows developers to keep using the same loops (and most of the APIs) they're already comfortable with, keeps DNS out of the kernel, but hopefully provides a better and easier to use connect() experience, for SOCK_STREAM at least. It's not as neat as a single connect() accepting a name, but seems to be a happy medium and provides a standardized/predictable connect() experience without breaking existing APIs. ~Matt