- 26 Sep, 2019 1 commit
-
-
Geoff Simmons authored
-
- 22 Sep, 2019 22 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
And update related parts of the docs.
-
Geoff Simmons authored
-
Geoff Simmons authored
POSIX requires that a file description is referenced by mmap(2), so the refcount does not reach 0 when the file is deleted while it is still mapped. So POSIX-compliant systems can be expected to retain the mapping after file deletion. Unless the VMOD goes to the trouble of copying the file, the safe way to update it is to delete it, then write a file with the same name with the new contents. A check may happen to run between deletion and the new write. But because of the property mentioned above, this is not a real problem for memory-mapped files. So the VMOD will work according to these rules: - If a check cannot read a file due to ENOENT, it is not an error. (It is an error if the file does not exist on initial read.) In that case, the file is considered unchanged -- the current mapping continues as the cached file contents. - This means that for the VMOD, a deleted file is *not* considered to be in error, provided it could be read initially (that is, it is already mapped). - We set a flag when the file is deleted, so that the condition can be detected. - Users are advised in the docs that the "delete, then write" procedure is the *only* method for updating the file that the VMOD supports. Other methods may work, some of the time, but you do it differently at your own risk. Also, access(2) is not a reliable means to determine if the file can be read and mapped, because if checks permissions against the real UID/GID, whereas open(2) depends on effective UID/GID. So: - checks begin with open(2), then use fstat(2) for the stat check. - Path searches are done by attempting open(2) with the filename on each directory in the path.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
distcheck does not allow writes into the build directory, so we can't use ${testdir}.
-
Geoff Simmons authored
-
Geoff Simmons authored
Prove that next_check() really runs when there is an error.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 21 Sep, 2019 13 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
There was much more busy-wait looping than I expected.
-
Geoff Simmons authored
-
Geoff Simmons authored
There are too many troubling possibilities for races otherwise. This also eliminates the arbitrary sleep time in the constructor.
-
Geoff Simmons authored
This falls out automatically from the use of POSIX timers, by setting the interval to 0. Whether or not the client nevertheless sees changes in the file is platform-dependent, since mmap(2) leaves this unspecified for MAP_PRIVATE. On Linux, changes are seen, and the mapping is retained after the file is deleted (until munmap).
-
- 20 Sep, 2019 4 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
And improve the error message a bit.
-
Geoff Simmons authored
-
Geoff Simmons authored
-