asynchronous - 在 OS X 上使用/dev/autofs_nowait 的风险和返回

Question

全程CoreFoundation framework source , POSIX 文件系统 API 调用(例如 open() 、 stat() 等...)是 wrapped in an idiom其中 /dev/autofs_nowait 上的描述符被收购 - 与 open(…, 0) – 在进行 POSIX 调用之前；之后描述符是 close() 'd 在范围退出之前。

这样做有什么好处？有哪些风险？

是否获取/dev/autofs_nowait描述符对任何这样包装的 open() 的标志有任何影响，或者是否受其影响调用(例如 O_NONBLOCK )？

/dev在我的机器上，运行 OS X 10.10.5 有其他“autofs”条目:

... 没有一个 man可用页面。如果这些类似文件的设备可能在这方面提供好处，我也有兴趣了解它们的用途，因为它可能适用。

附录:我在这个主题上找不到太多； Google Plus post from 2011声称:

[t]his file is a special device that's monitored by the autofs filesystem implementation in the kernel. When opened, the autofs filesystem will not block that process on any I/O operations on an autofs file system.

我不太确定这意味着什么(他们专门谈论 launchd 是如何工作的，FWIW)但我自己对此很好奇，所以我写了 a quick context-manager-y RAII struct至 try it out – 非目标分析显示测试与 POSIX 调用完成得更快但在一般哈希标记内；在获得有关其运作方式的更多背景知识后，我将使用更细齿的梳子研究这种策略。

Answer 1

这些设备允许实现者避免定义新的 syscall或 ioctl对于功能，也许它是这样实现的，因为它更简单，需要更新的代码更少，并且不会更改 VFS API，这可能是当时的担忧。

当您打开 /dev/autofs_nowait并遍历路径，您会触发自动挂载，但不要等待它们完成(否则您的进程会阻塞直到文件系统被挂载或操作超时)，因此您可能会收到 ENOENT打开文件时，即使一切正常。

奥托, /dev/autofs_notrigger使该过程甚至不会触发自动安装。

这就是所有这些设备所做的。问题是，在达尔文的实现中，open即使使用 O_NONBLOCK 遍历文件系统时也可能会阻塞或 O_NDELAY .

您可以遵循 vfs 中的流程，来自 open vnode的操作:

vn_open -> vn_open_auth ->

namei -> lookup -> ...

在这条路上，没有处理(非)阻塞行为。