On Thursday, March 22, 2018 at 6:51:58 AM UTC-5, Anders Hallström wrote: > > First I ask for a clarification of the behavior of uv_close. > > Doc says "Handles that wrap file descriptors are closed immediately > but..." However it does not clearly say that the wrapped file descriptor is > closed. It is perhaps obvious that this is the reasonable behavior, but I > ask anyway, for a reason. >
I am not speaking for libuv team, but you can check sources, e.g.: https://github.com/libuv/libuv/blob/9ed3ed5fcb3f19eccd3d29848ae2ff0cfd577de9/src/unix/core.c#L116 https://github.com/libuv/libuv/blob/9ed3ed5fcb3f19eccd3d29848ae2ff0cfd577de9/src/unix/core.c#L536 > I write code that combines libuv with another event handler, we can call > it "eventlib". I do this for legacy reasons. > I let eventlib create a socket connection, then I let uv wrap a TCP handle > around it using uv_tcp_open(handle, fd). > It should be noted that the socket file descriptor was not opened by uv. > > Later at cleanup time I want to detach the uv TCP handle from this fd and > close the handle; ideally I would like to restore the state to before > uv_tcp_open was called, meaning close the handle without closing the fd; > since uv did not open the fd. Then I can call the eventlib methods to close > its handles and implicitly close the fd; since eventlib did open the fd. > > However, the only tool I can find to do this is uv_close(handle) and I > guess it will close handle as well as its associated fd. So both eventlib > and libuv want to close the same fd, perhaps harmless but not nice. > not harmless -- this fd will be reused and you'll end up with surprises. > Should I instead duplicate the fd opened by eventlib and give the > duplicate to libuv? Then eventlib and uv will each have its own fd > describing the same socket, and it avoids the risk of closing the same fd > twice. This solution however assumes that uv_close will indeed close the > fd. So again, the clarification please. > Duplication may work, but as far as I remember epoll was doing some very magical things with fd -- as in "using file description instead file descriptor", so you end up with very weird behaviour if you try to watch two different fds referring to the same kernel object. I would proceed with caution. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
