dup2真的能返回EINTR吗？

Question

在规范和两个实现中：

• 根据POSIX，dup2()可以返回EINTR。
• linux手册页列出了允许的内容。
• FreeBSD手册页显示它从未被返回。这是一个bug吗?因为它的密切实现可以EINTR (至少对于TCP徘徊，如果没有其他)。

实际上，Linux可以返回dup2()的EINTR吗？如果是这样的话，可能是因为close()决定等待，一个信号到达了(TCP徘徊或文件系统驱动程序试图在关闭时同步)。

实际上，FreeBSD是否保证不为dup2()返回EINTR？在这种情况下，它肯定不需要等待旧fd上任何悬而未决的操作，而只是断开fd的链接。

当dup2()引用“关闭”(而不是斜体)，而不是引用实际的close()函数时，它意味着什么?我们理解它只是以非正式的方式(断开文件描述符)来“关闭”它，还是试图说效果应该是close()函数首先被调用，然后dup2()被原子地调用。

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

如果dup2()真的必须关闭，等待，然后原子地dup，对实现者来说，这将是一场噩梦！这比close()惨败的EINTR要糟糕得多。懦弱的POSIX甚至没有说dup是否发生在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的函数都是这样列出的，这表明这些函数不是这样的。注意，这些函数是通过fcntl实现的，而不是对close的调用。