dup2真的可以返回EINTR吗？

Question

在规范和两个实现中：

• 根据 POSIX，dup2()可能会返回 EINTR。
• Linux 手册页将其列为允许的。
• FreeBSD 手册页表明它从未返回过。这是一个错误吗 - 因为它的关闭实现可以 EINTR （至少对于 TCP linger 如果没有其他的话）。

实际上，Linux 可以返回 EINTR 吗dup2()？如果是这样的话，大概是因为close()决定等待并且信号到达（TCP 延迟或狡猾的文件系统驱动程序在关闭时尝试同步）。

实际上，FreeBSD 能保证不返回 EINTR 吗dup2()？在这种情况下，它一定不会等待旧 fd 上的任何未完成的操作，而是简单地取消链接该 fd。

当POSIXdup2()指的是“关闭”（不是斜体）而不是指实际的函数时，它意味着什么close()- 我们是否理解它只是以非正式的方式谈论“关闭”它（取消文件描述符的链接），或者它是试图说效果应该就像close()首先调用该函数然后dup2()以原子方式调用一样。

如果fildes2已经是一个有效的打开文件描述符，则应首先关闭它，除非fildes等于fildes2，在这种情况下，dup2()应返回fildes2而不关闭它。

如果dup2() 必须关闭、等待，然后自动复制，这对于实现者来说将是一场噩梦！这比惨败的 EINTR 还要糟糕得多close()。胆怯的 POSIX 甚至没有说在 EINTR 的情况下是否发生了重复......

Answer 1

以下是 C/POSIX 库文档中有关标准 Linux 实现的相关信息：

 If OLD and NEW are different numbers, and OLD is a valid
 descriptor number, then `dup2' is equivalent to:

      close (NEW);
      fcntl (OLD, F_DUPFD, NEW)

 However, `dup2' does this atomically; there is no instant in the
 middle of calling `dup2' at which NEW is closed and not yet a
 duplicate of OLD.

dup它将和返回的可能错误值列出dup2为EBADF、EINVAL、 和EMFILE，没有其他值。文档指出所有可以返回 EINTR 的函数都按此列出，这表明这些函数不能返回 EINTR。请注意，这些是通过实现的fcntl，而不是调用close。