Watch Service API是否识别内存映射文件？
共有1个答案
这取决于您创建的打开和修改文件的文件映射。
像传统的文件句柄一样，文件映射可以是可写或只读的。
前两种映射模式mapmode.read_only和mapmode.read_write非常明显。它们指示您是希望映射是只读的，还是允许修改映射文件。
StandardWatchEventKinds.entry_create-在监视目录中出现新条目时触发。可能是因为创建了新文件或重命名了现有文件。StandardWatchEventKinds.entry_modify-当监视目录中的现有条目被修改时触发。所有文件编辑触发此事件。在某些平台上，甚至更改文件属性也会触发它。StandardWatchEventKinds.entry_delete-在监视目录中删除、移动或重命名条目时触发。StandardWatchEventKinds.Overflow-触发以指示丢失或丢弃的事件。我们不会过多关注它
考虑到这一点，以下可以说...
- 如果映射模式为
read_only，则不会激发上述事件，因此不会进行检测。 - 如果映射模式为
private，则不会激发上述事件，因为您正在处理文件的私有副本。 - 现在最有趣的情况是
read_write。因为它会在某个时候修改磁盘驱动器上的文件，所以在某个时候会通知操作系统，然后它会通知WatchServiceAPI.
The implementation that observes events from the file system is intended to map directly on to the native file event notification facility where available, or to use a primitive mechanism, such as polling, when a native facility is not available. Consequently, many of the details on how events are detected, their timeliness, and whether their ordering is preserved are highly implementation specific. For example, when a file in a watched directory is modified then it may result in a single ENTRY_MODIFY event in some implementations but several events in other implementations. Short-lived files (meaning files that are deleted very quickly after they are created) may not be detected by primitive implementations that periodically poll the file system to detect changes.
If a watched file is not located on a local storage device then it is implementation specific if changes to the file can be detected. In particular, it is not required that changes to files carried out on remote systems be detected.
-
问题内容： 我用np.save（）保存了几个numpy数组，并将它们放在一起非常大。 是否可以将它们全部加载为内存映射文件，然后对它们进行串联和切片，而无需将任何内容都加载到内存中？ 问题答案： 使用显然将数组加载到内存中。为避免这种情况，您可以轻松地在新文件中创建一个thrid数组，并从要连接的数组中读取值。以更有效的方式，您还可以将新阵列追加到磁盘上已存在的文件中。 在任何情况下，您都必须为数
-
读 # mmap_read.py import mmap with open('lorem.txt', 'r') as f: with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as m: print('First 10 bytes via read :', m.read(10
-
问题内容： 最近，我碰到了这篇文章，这篇文章很好地介绍了内存映射文件以及如何在两个进程之间共享它。这是读取文件的过程的代码： 但是，我对这种方法有几点评论/问题： 如果我们仅对空文件执行读取器，即运行 这将分配8000个字节，现在将扩展文件。返回的缓冲区的限制为8000，位置为0，因此，读取器可以继续读取空数据。发生这种情况后，阅读器将停止，如。 现在应该是作家了（代码被省去了，因为它很简单，可以
-
系统调用在调用进程的虚拟地址空间中提供映射，将文件或设备映射到内存中。 下面是两种类型 - 文件映射或文件支持的映射 - 此映射将进程的虚拟内存区域映射到文件。 这意味着读取或写入这些内存区域会导致文件被读取或写入。这是默认的映射类型。 匿名映射 - 此映射映射进程的虚拟内存区域，不受任何文件的支持。 内容被初始化为零。 这种映射类似于动态内存分配(malloc())，在某些实现中用于某些分配。
-
OpenGL和Vulkan都允许通过分别使用和来获取指向部分GPU内存的指针。它们都为映射的内存提供了。要将其内容解释为一些数据，必须将其转换为适当的类型。最简单的例子可以是转换为以将内存解释为浮点数或向量或类似数组。 似乎任何类型的内存映射在C中都是未定义的行为，因为它没有内存映射的概念。但是，这并不是真正的问题，因为这个主题超出了C标准的范围。但是，仍然存在的问题。 在链接问题中，指针被额外标
-
问题内容： 我一直在尝试编写一些非常快速的Java代码，这些代码必须执行很多I / O。我正在使用返回ByteBuffer的内存映射文件： 我遇到的问题是ByteBuffer .array（）方法（应返回一个byte []数组）不适用于只读文件。我想编写我的代码，以便它可以与构造在内存中的内存缓冲区和从磁盘读取的缓冲区一起使用。但是我不想将所有缓冲区都包装为ByteBuffer.wrap（）函数，