- 26 Jan, 2022 1 commit
-
-
Geoff Simmons authored
-
- 01 Mar, 2021 3 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
The PRIV_VCL list is now a list of reader objects. On the warm event, we restart the timer and then wait for the first check to run, as in object init.
-
Geoff Simmons authored
Rather than contain it entirely, in the continued effort for better cacheline-friendliness. This is a considerable improvement, but we're still not quite there.
-
- 28 Feb, 2021 10 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
The update check works on copies of the info struct, flags, etc. Only take the write lock when all work is finished, then copy data back under the lock.
-
Geoff Simmons authored
Can't rule out error messages longer than 256 chars.
-
Geoff Simmons authored
Still very cacheline-unfriendly.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 26 Feb, 2021 3 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 15 Sep, 2020 1 commit
-
-
Nils Goroll authored
-
- 01 Sep, 2020 1 commit
-
-
Geoff Simmons authored
-
- 17 Dec, 2019 1 commit
-
-
Geoff Simmons authored
(Not before.) Fixes #1
-
- 31 Oct, 2019 6 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 28 Sep, 2019 1 commit
-
-
Geoff Simmons authored
-
- 26 Sep, 2019 3 commits
-
-
Geoff Simmons authored
The thought was to shorten the time spent under the lock. But it actually introduces a race.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 22 Sep, 2019 10 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
-