On May 16, 2014, at 11:28 AM, Bardwell, William <wbard...@akamai.com> wrote:
> 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 think the mutex might be needed if you deliver the NET_EVENT_OPEN events when you create the VConn. this API does not deliver those events; it succeeds or fails immediately > (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.) Yeh, I think the name is a mixed bag. "From" is usually used with reference to the network data flow direction TSCacheKeyDigestFromUrlSet, INKUDPPacketFromPortGet, etc. TSVConnCreateFromFd scans better, but we do have a strong convention to end API names with the verb. > 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(). That sounds *very* like my patch :) > (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
