I love it...in fact I already implemented this against 3.2.X for a similar use. I called it TSVConnFromFdCreate(), I had it taking a mutex (that could be NULL) as well, but not sure if that is really needed. (I liked the "From" part of the name to make it clear that it wasn't making and Fd inside the VConn...but same diff.) In in turn called: NetVConnection *UnixNetProcessor::vconn_from_fd(int fd, ProxyMutex * mutex, NetVCOptions * opt) which is a pretty short variant of the code that is used to make a VConn after accept() or connect().
(Sorry, I just hadn't had time yet to try to get legal approval to upstream the code.) -William ________________________________________ From: James Peach [jpe...@apache.org] Sent: Friday, May 16, 2014 11:07 AM To: dev@trafficserver.apache.org Subject: Re: [API REVIEW] TSVConnFdCreat On May 15, 2014, at 8:07 AM, James Peach <jpe...@apache.org> wrote: > Hi all, > > I'm proposing a new API, TSVConnFdCreate. > > TSVConn TSVConnFdCreate(int fd) > > TSVConnFdCreate accepts a file descriptor and returns a new TSVConn that > wraps that file descriptor. The file descriptor must be a connected socket. > The resulting TSVConn can be used with the standard TS I/O API. If the call > returns successfully, the returned TSVConn owns the socket and the caller > must not close(2) it. If TSVConnFdCreate() returns NULL, the socket is > unchanged and the caller must for close(2) it. > > My use case for this is to stitch a server intercept to an external API that > vends a connected socket. FWIW, this is https://issues.apache.org/jira/browse/TS-2810 J
