| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
PiperOrigin-RevId: 520172744
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are a couple differences between ChromiumEnv and
PosixEnv/WindowsEnv which cause test failures that are fixed (or at
least patched over) in this change:
* NewSequentialFile() and NewRandomAccessFile() return Status::IOError
rather than Status::NotFound when a file is not found, due to
https://crbug.com/760362. This means a few tests need to expect a
different error result.
* GetChildren() never returns the '.' or '..' entries.
* As allowed by the documentation for Env::Schedule(), ChromiumEnv may
execute functions on multiple threads and guarantees no sequencing.
EnvTest.RunMany assumed that functions ran in order. The test has been
updated.
|
|/
|
|
|
|
|
|
| |
As allowed by the documentation for Env::Schedule(), ChromiumEnv may
execute functions on multiple threads and guarantees no sequencing.
EnvTest.RunMany assumed that functions ran in order, is the case for the
stock PosixEnv and WindowsEnv implementations. This change updates the
test to not assume sequential execution.
|
|\
| |
| |
| | |
PiperOrigin-RevId: 420787858
|
| |\ |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 420781374
|
| |\ \ \
| | | |/
| | |/| |
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | | |
PiperOrigin-RevId: 420778907
|
| |/ /
| | |
| | | |
LRUHandle has no member "next_", fix it to "next" instead.
|
|\ \ \
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 420662938
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
PiperOrigin-RevId: 420644954
|
| |/ / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
PiperOrigin-RevId: 420504266
|
| | | | | |
|
| | | | | |
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This gives some flexibility to embedders.
Currently, embedders have to build a binary for each test file.
After this CL, embedders can still choose to have a binary for each test
file, by linking each test file with a googletest target that includes
main() (usually "gtest_main"). Embedders can also choose to build a
single binary for almost all test files, and link with a googletest
target that includes main(). The latter is more convenient for projects
that have very few test binaries, like Chromium.
PiperOrigin-RevId: 419470798
|
| | | |
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 417853172
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
PiperOrigin-RevId: 412997201
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I recently encountered a problem with this because Windows doesn't allow
files to be deleted when there's open handles to them.
Other files opened by leveldb are not affected because by and large they
are using CreateFileA, which does not allow inheritance when
lpSecurityAttributes is null (ref:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea)
However, fopen() _does_ allow inheritance, and it needs to be expressly
disabled.
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-160
|
| | | | | |
|
| |/ / /
|/| | |
| | | |
| | | | |
PiperOrigin-RevId: 395824737
|
|/ / /
| | |
| | |
| | | |
PiperOrigin-RevId: 329720018
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 309136120
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 309110431
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This CL makes the following substitutions.
* assert.h -> cassert
* math.h -> cmath
* stdarg.h -> cstdarg
* stddef.h -> cstddef
* stdint.h -> cstdint
* stdio.h -> cstdio
* stdlib.h -> cstdlib
* string.h -> cstring
PiperOrigin-RevId: 309080151
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 307113877
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Clang 10 includes the optimizations described in
https://bugs.llvm.org/show_bug.cgi?id=41761. This means that the
platform-independent implementations of {Decode,Encode}Fixed{32,64}()
compile to one instruction on the most recent Clang and GCC.
PiperOrigin-RevId: 306330166
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
leveldb::Env::DeleteFile was replaced with leveldb::Env::RemoveFile in
all tests. This allows us to remove workarounds for windows.h #defining
DeleteFile.
PiperOrigin-RevId: 289121105
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The "DeleteFile" method name causes pain for Windows developers, because
<windows.h> #defines a DeleteFile macro to DeleteFileW or DeleteFileA.
Current code uses workarounds, like #undefining DeleteFile everywhere an
Env is declared, implemented, or used.
This CL removes the need for workarounds by renaming Env::DeleteFile to
Env::RemoveFile. For consistency, Env::DeleteDir is also renamed to
Env::RemoveDir. A few internal methods are also renamed for consistency.
Software that supports Windows is expected to migrate any Env
implementations and usage to Remove{File,Dir}, and never use the name
Env::Delete{File,Dir} in its code.
The renaming is done in a backwards-compatible way, at the risk of
making it slightly more difficult to build a new correct Env
implementation. The backwards compatibility is achieved using the
following hacks:
1) Env::Remove{File,Dir} methods are added, with a default
implementation that calls into Env::Delete{File,Dir}. This makes old
Env implementations compatible with code that calls into the updated
API.
2) The Env::Delete{File,Dir} methods are no longer pure virtuals.
Instead, they gain a default implementation that calls into
Env::Remove{File,Dir}. This makes updated Env implementations
compatible with code that calls into the old API.
The cost of this approach is that it's possible to write an Env without
overriding either Rename{File,Dir} or Delete{File,Dir}, without getting
a compiler warning. However, attempting to run the test suite will
immediately fail with an infinite call stack ending in
{Remove,Delete}{File,Dir}, making developers aware of the problem.
PiperOrigin-RevId: 288710907
|
| | |
| | |
| | |
| | |
| | |
| | | |
Env::DeleteFile.
PiperOrigin-RevId: 283607548
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 282373286
|
|/ /
| |
| |
| | |
PiperOrigin-RevId: 281815695
|
| |
| |
| |
| | |
PiperOrigin-RevId: 268265314
|
| |
| |
| |
| |
| |
| | |
Fixes #695.
PiperOrigin-RevId: 252895299
|
| |
| |
| |
| | |
PiperOrigin-RevId: 250383036
|
| |
| |
| |
| | |
PiperOrigin-RevId: 250309603
|
| |
| |
| |
| |
| |
| | |
Fixes issue #684.
PiperOrigin-RevId: 249531001
|
| |
| |
| |
| | |
PiperOrigin-RevId: 247491163
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The previous attempt of having EnvPosix use O_CLOEXEC (close-on-exec()) when opening file descriptors added tests that relied on procfs, which is Linux-specific. These tests failed on macOS. Unfortunately, the test failures were not caught due to a (since fixed) error in our Travis CI configuration.
This CL re-structures the tests to only rely on POSIX features. Since there is no POSIX-compliant way to get a file name/path out of a file descriptor, this CL breaks up the O_CLOEXEC test into multiple tests, where each Env method that creates an FD gets its own test. This is intended to make it easier to find and fix errors in Env implementations.
This CL also fixes the implementation of NewLogger() to use O_CLOEXEC on macOS. The current implementation passes "we" to fopen(), but the macOS standard C library does not implement the "e" flag yet.
PiperOrigin-RevId: 247088953
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Two minor corrections to correct the 900f7d37eb322 commit
to conform to the Google C++ style guide.
PiperOrigin-RevId: 246907647
|
| |\ \
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 246903086
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This prevents file descriptors from leaking to child processes.
When compiled for older (pre-2.6.23) kernels which lack support for
O_CLOEXEC there is no change in behavior. With newer kernels, child
processes will no longer inherit leveldb's file handles, which
reduces the changes of accidentally corrupting the database.
Fixes https://github.com/google/leveldb/issues/623
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1) Inline EncodeFixed{32,64}(). They emit single machine instructions on 64-bit processors.
2) Remove size narrowing compiler warnings from DecodeFixed{32,64}().
3) Add comments explaining the current state of optimizations in compilers we care about.
4) Change C-style includes, like <stdint.h>, to C++ style, like <cstdint>.
5) memcpy -> std::memcpy.
The optimization comments are based on https://godbolt.org/z/RdIqS1. The missed optimization opportunities in clang have been reported as https://bugs.llvm.org/show_bug.cgi?id=41761
The change does not have significant impact on benchmarks. Results below.
LevelDB: version 1.22
Date: Mon May 6 10:42:18 2019
CPU: 72 * Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz
CPUCache: 25344 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 1000000
RawSize: 110.6 MB (estimated)
FileSize: 62.9 MB (estimated)
With change
------------------------------------------------
fillseq : 2.327 micros/op; 47.5 MB/s
fillsync : 4185.526 micros/op; 0.0 MB/s (1000 ops)
fillrandom : 3.662 micros/op; 30.2 MB/s
overwrite : 4.261 micros/op; 26.0 MB/s
readrandom : 4.239 micros/op; (1000000 of 1000000 found)
readrandom : 3.649 micros/op; (1000000 of 1000000 found)
readseq : 0.174 micros/op; 636.7 MB/s
readreverse : 0.271 micros/op; 408.7 MB/s
compact : 570495.000 micros/op;
readrandom : 2.735 micros/op; (1000000 of 1000000 found)
readseq : 0.118 micros/op; 937.3 MB/s
readreverse : 0.190 micros/op; 583.7 MB/s
fill100K : 860.164 micros/op; 110.9 MB/s (1000 ops)
crc32c : 1.131 micros/op; 3455.2 MB/s (4K per op)
snappycomp : 3.034 micros/op; 1287.5 MB/s (output: 55.1%)
snappyuncomp : 0.544 micros/op; 7176.0 MB/s
Baseline
------------------------------------------------
fillseq : 2.365 micros/op; 46.8 MB/s
fillsync : 4240.165 micros/op; 0.0 MB/s (1000 ops)
fillrandom : 3.244 micros/op; 34.1 MB/s
overwrite : 4.153 micros/op; 26.6 MB/s
readrandom : 4.698 micros/op; (1000000 of 1000000 found)
readrandom : 4.065 micros/op; (1000000 of 1000000 found)
readseq : 0.192 micros/op; 576.3 MB/s
readreverse : 0.286 micros/op; 386.7 MB/s
compact : 635979.000 micros/op;
readrandom : 3.264 micros/op; (1000000 of 1000000 found)
readseq : 0.169 micros/op; 652.8 MB/s
readreverse : 0.213 micros/op; 519.5 MB/s
fill100K : 1055.367 micros/op; 90.4 MB/s (1000 ops)
crc32c : 1.353 micros/op; 2887.3 MB/s (4K per op)
snappycomp : 3.036 micros/op; 1286.7 MB/s (output: 55.1%)
snappyuncomp : 0.540 micros/op; 7238.6 MB/s
PiperOrigin-RevId: 246856811
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1) Convert iterator-based for loops to C++11 foreach loops.
2) Convert "void operator=" to "T& operator=".
3) Switch from copy operators from private to public deleted.
4) Switch from empty ctors / dtors to "= default" where appropriate.
PiperOrigin-RevId: 246679195
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1. Correct the class/struct declaration order to be IAW
the Google C++ style guide[1].
2. For non-copyable classes, switched from non-implemented
private methods to explicitly deleted[2] methods.
3. Minor const and member initialization fixes.
[1] https://google.github.io/styleguide/cppguide.html#Declaration_Order
[2] http://eel.is/c++draft/dcl.fct.def.delete
PiperOrigin-RevId: 246521844
|