你好 关于 open_socket 局部代码疑问, 是否有 socket fd 泄露?

[wangzhione]

https://github.com/cloudwu/skynet/blob/master/skynet-src/socket_server.c#L664-L668

下面是看代码分析过程, 你看逻辑是否有问题呢 ? 感谢指正

1. socket_server_poll 执行
2. socket_server_connect 执行
   -> open_request 执行
   -> reserve_id 执行 得到一个 id, 其中 struct socket *s = &ss->slot[HASH_ID(id)]; 并且 s->type 设置为 SOCKET_TYPE_RESERVE
3. socket_server_poll 中 has_cmd 执行 -> ctrl_cmd 执行
   -> case 'O' : return open_socket 执行. 这时候假定 EINPROGRESS 执行到 L664-L668 enable_write error -> goto _failed
   此刻 s->type = SOCKET_TYPE_CONNECTING
   跳转到 https://github.com/cloudwu/skynet/blob/master/skynet-src/socket_server.c#L673-L677
   (疑惑点)此时 s->type 从 SOCKET_TYPE_CONNECTING 修改为 SOCKET_TYPE_INVALID 进入备用 socket slot 池子中.
   执行完毕 return SOCKET_ERR;

但是 sock = socket( ai_ptr->ai_family, ai_ptr->ai_socktype, ai_ptr->ai_protocol ); 没有 close 啊 如果假设成立包括 在 new_fd 之前注册的 enable_read 也需要处理?

还有另外一个疑惑点, 对于

struct socekt {
ATOM_INT type;
};
ss->slot[HASH_ID(id)].type = SOCKET_TYPE_INVALID;
这种赋值方式是否不推荐啊, 不应该使用 ATOM_STORE 吗? (虽然大多数平台 int 直接赋值是也难有bug)

[cloudwu]

谢谢。这里有问题，是代码更迭引起的。
原本 enable write 是不检查错误的，77311c7

stdatomic 也是后面改的，改漏了。

[cloudwu]

b13281b 这个提交修了这个问题。

[wangzhione]

关于这个修改还有个疑问?
修改的 open_socket 中 ns = new_fd(ss, id, sock, PROTOCOL_TCP, request->opaque, true); 成功返回后, 内部 enable_read(ss, s, reading) 执行也已经成功.

随后 goto close socket fd 地方.

linux 上 man epoll 发现

   Q6  Will closing a file descriptor cause it to be removed from all epoll sets automatically?

   A6  Yes, but be aware of the following point.  A file descriptor is  a  reference  to  an  open  file
       description  (see  open(2)).   Whenever  a  file  descriptor  is  duplicated via dup(2), dup2(2),
       fcntl(2) F_DUPFD, or fork(2), a new file descriptor referring to the same open  file  description
       is  created.  An open file description continues to exist until all file descriptors referring to
       it have been closed.  A file descriptor is removed from an epoll set  only  after  all  the  file
       descriptors  referring to the underlying open file description have been closed (or before if the
       file descriptor is explicitly removed using epoll_ctl(2) EPOLL_CTL_DEL).  This  means  that  even
       after  a file descriptor that is part of an epoll set has been closed, events may be reported for
       that file descriptor if other file descriptors referring to the same underlying file  description
       remain open.

在 fd 被引用数 <= 0 会被自动 epoll_ctl EPOLL_CTL_DEL.

但查阅 kqueue 没有相关细节介绍, 多数代码也是主动去处理. 目前没有 unix 机器可以去测试. 或者是否需要显示的执行 sp_del 呢?

[cloudwu]

我的理解是，如果 fd 被 close ，似乎底层也没有必要在监听 集合中留着它。因为 fd 是会被复用的，如果在监听集中保留就相当于 close 无法关闭 fd 。如果底层这么设计，势必有更多潜在问题。除了 epoll ，我相信其它的 api 也会是一样的设计。

从对称的角度，调用 sp_del 更完整一些，但不只是这次修改的地方， new_fd 那里有个分支也需要改。我暂时倾向于不动。想法是：在正常路径上用 sp_del ，在异常路径上依赖系统自己的回收。