c - 在 ioctl 中打开的不良副作用是什么？

Question

根据 man ioctl，使用 open 打开文件描述符可能会导致不需要的副作用。该手册还指出，使用 O_NONBLOCK 打开可以解决那些不需要的问题，但我似乎无法找到原因是什么，也不知道实际的副作用是什么。有人可以阐明这一点吗？使用 ioctl 是否总是可以并等效于*使用 O_NONBLOCK 打开文件描述符？

NOTES (from man ioctl)

In order to use this call, one needs an open file descriptor. Often the open(2) call has unwanted side effects, that can be avoided under Linux by giving it the O_NONBLOCK flag.

(* 我知道 O_NONBLOCK 意味着什么，但我不知道这是否会影响 ioctl 调用，就像它影响其他系统调用一样。我的程序，使用 ioctl 写入和读取 SPI 总线，在启用该标志的情况下完美工作。)

Answer 1

寻找答案的明显位置是 open(2)手册页，在 O_NONBLOCK 的标题下，说:

When possible, the file is opened in nonblocking mode. Neither the open() nor any subsequent operations on the file descriptor which is returned will cause the calling process to wait.

[...]

For the handling of FIFOs (named pipes), see also fifo(7). For a discussion of the effect of O_NONBLOCK in conjunction with mandatory file locks and with file leases, see fcntl(2).

好吧，这不是很有用，但让我们点击链接，看看 fifo(7) 和 fcntl(2) 的手册页是怎么说的:

Normally, opening the FIFO blocks until the other end is opened also.

A process can open a FIFO in nonblocking mode. In this case, opening for read-only will succeed even if no-one has opened on the write side yet and opening for write-only will fail with ENXIO (no such device or address) unless the other end has already been opened.

Under Linux, opening a FIFO for read and write will succeed both in blocking and nonblocking mode. POSIX leaves this behavior undefined.

所以这里至少有一个“不需要的副作用”:即使只是尝试打开 FIFO 也可能会阻塞，除非您将 O_NONBLOCK 传递给 open() 调用(并且打开阅读)。

那么 fcntl 呢？正如 open(2) 手册页所指出的，要查看的部分是标题为“强制锁定”和“文件租用”的部分。在我看来，似乎，在这种情况下，强制锁是一个转移注意力的问题，不过它们只会在有人尝试实际读取或写入文件时导致阻塞:

If a process tries to perform an incompatible access (e.g., read(2) or write(2)) on a file region that has an incompatible mandatory lock, then the result depends upon whether the O_NONBLOCK flag is enabled for its open file description. If the O_NONBLOCK flag is not enabled, then the system call is blocked until the lock is removed or converted to a mode that is compatible with the access.

那么租约呢？

When a process (the "lease breaker") performs an open(2) or truncate(2) that conflicts with a lease established via F_SETLEASE, the system call is blocked by the kernel and the kernel notifies the lease holder by sending it a signal (SIGIO by default). [...]

Once the lease has been voluntarily or forcibly removed or downgraded, and assuming the lease breaker has not unblocked its system call, the kernel permits the lease breaker's system call to proceed.

[...] If the lease breaker specifies the O_NONBLOCK flag when calling open(2), then the call immediately fails with the error EWOULDBLOCK, but the other steps still occur as described above.

好的，这是另一个不需要的副作用:如果您尝试打开的文件有租约，则 open() 调用可能会阻塞，直到租约持有者释放租约。

在这两种情况下，通过将 O_NONBLOCK 传递给 open() 而避免的“不需要的副作用”是，不出所料，open()调用自身阻塞，直到其他进程完成某事。如果您引用的手册页提到了任何其他类型的副作用，我不知道它们。