2011-03-19 06:37:00 +08:00
|
|
|
// Copyright (c) 2011 The LevelDB Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file. See the AUTHORS file for names of contributors.
|
|
|
|
|
2011-03-31 02:35:40 +08:00
|
|
|
#include "leveldb/env.h"
|
2011-03-19 06:37:00 +08:00
|
|
|
|
2017-10-05 01:04:21 +08:00
|
|
|
#include <algorithm>
|
|
|
|
|
2019-11-26 01:29:06 +08:00
|
|
|
#include "gtest/gtest.h"
|
2011-03-19 06:37:00 +08:00
|
|
|
#include "port/port.h"
|
2018-03-24 03:50:14 +08:00
|
|
|
#include "port/thread_annotations.h"
|
|
|
|
#include "util/mutexlock.h"
|
2017-10-03 03:37:45 +08:00
|
|
|
#include "util/testutil.h"
|
2011-03-19 06:37:00 +08:00
|
|
|
|
|
|
|
namespace leveldb {
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
class EnvTest : public testing::Test {
|
2011-03-19 06:37:00 +08:00
|
|
|
public:
|
2019-05-03 02:01:00 +08:00
|
|
|
EnvTest() : env_(Env::Default()) {}
|
2019-05-04 00:31:18 +08:00
|
|
|
|
|
|
|
Env* env_;
|
2011-03-19 06:37:00 +08:00
|
|
|
};
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
TEST_F(EnvTest, ReadWrite) {
|
2017-10-03 03:37:45 +08:00
|
|
|
Random rnd(test::RandomSeed());
|
|
|
|
|
|
|
|
// Get file to use for testing.
|
|
|
|
std::string test_dir;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->GetTestDirectory(&test_dir));
|
2017-10-03 03:37:45 +08:00
|
|
|
std::string test_file_name = test_dir + "/open_on_read.txt";
|
2017-10-04 01:38:02 +08:00
|
|
|
WritableFile* writable_file;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->NewWritableFile(test_file_name, &writable_file));
|
2017-10-03 03:37:45 +08:00
|
|
|
|
|
|
|
// Fill a file with data generated via a sequence of randomly sized writes.
|
|
|
|
static const size_t kDataSize = 10 * 1048576;
|
|
|
|
std::string data;
|
|
|
|
while (data.size() < kDataSize) {
|
|
|
|
int len = rnd.Skewed(18); // Up to 2^18 - 1, but typically much smaller
|
|
|
|
std::string r;
|
|
|
|
test::RandomString(&rnd, len, &r);
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(writable_file->Append(r));
|
2017-10-03 03:37:45 +08:00
|
|
|
data += r;
|
|
|
|
if (rnd.OneIn(10)) {
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(writable_file->Flush());
|
2017-10-03 03:37:45 +08:00
|
|
|
}
|
|
|
|
}
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(writable_file->Sync());
|
|
|
|
ASSERT_LEVELDB_OK(writable_file->Close());
|
2017-10-04 01:38:02 +08:00
|
|
|
delete writable_file;
|
2017-10-03 03:37:45 +08:00
|
|
|
|
|
|
|
// Read all data using a sequence of randomly sized reads.
|
2017-10-04 01:38:02 +08:00
|
|
|
SequentialFile* sequential_file;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->NewSequentialFile(test_file_name, &sequential_file));
|
2017-10-03 03:37:45 +08:00
|
|
|
std::string read_result;
|
|
|
|
std::string scratch;
|
|
|
|
while (read_result.size() < data.size()) {
|
|
|
|
int len = std::min<int>(rnd.Skewed(18), data.size() - read_result.size());
|
|
|
|
scratch.resize(std::max(len, 1)); // at least 1 so &scratch[0] is legal
|
|
|
|
Slice read;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(sequential_file->Read(len, &read, &scratch[0]));
|
2017-10-03 03:37:45 +08:00
|
|
|
if (len > 0) {
|
|
|
|
ASSERT_GT(read.size(), 0);
|
|
|
|
}
|
|
|
|
ASSERT_LE(read.size(), len);
|
|
|
|
read_result.append(read.data(), read.size());
|
|
|
|
}
|
|
|
|
ASSERT_EQ(read_result, data);
|
2017-10-04 01:38:02 +08:00
|
|
|
delete sequential_file;
|
2017-10-03 03:37:45 +08:00
|
|
|
}
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
TEST_F(EnvTest, RunImmediately) {
|
2019-09-11 02:09:31 +08:00
|
|
|
struct RunState {
|
|
|
|
port::Mutex mu;
|
|
|
|
port::CondVar cvar{&mu};
|
|
|
|
bool called = false;
|
|
|
|
|
|
|
|
static void Run(void* arg) {
|
|
|
|
RunState* state = reinterpret_cast<RunState*>(arg);
|
|
|
|
MutexLock l(&state->mu);
|
|
|
|
ASSERT_EQ(state->called, false);
|
|
|
|
state->called = true;
|
|
|
|
state->cvar.Signal();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
RunState state;
|
|
|
|
env_->Schedule(&RunState::Run, &state);
|
|
|
|
|
|
|
|
MutexLock l(&state.mu);
|
|
|
|
while (!state.called) {
|
|
|
|
state.cvar.Wait();
|
|
|
|
}
|
2011-03-19 06:37:00 +08:00
|
|
|
}
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
TEST_F(EnvTest, RunMany) {
|
2019-09-11 02:09:31 +08:00
|
|
|
struct RunState {
|
|
|
|
port::Mutex mu;
|
|
|
|
port::CondVar cvar{&mu};
|
2023-03-29 07:20:01 +08:00
|
|
|
int last_id = 0;
|
2019-09-11 02:09:31 +08:00
|
|
|
};
|
2011-03-19 06:37:00 +08:00
|
|
|
|
2019-03-12 04:04:53 +08:00
|
|
|
struct Callback {
|
2023-03-29 07:20:01 +08:00
|
|
|
RunState* state_; // Pointer to shared state.
|
|
|
|
const int id_; // Order# for the execution of this callback.
|
2011-03-19 06:37:00 +08:00
|
|
|
|
2023-03-29 07:20:01 +08:00
|
|
|
Callback(RunState* s, int id) : state_(s), id_(id) {}
|
2011-03-19 06:37:00 +08:00
|
|
|
|
2019-03-12 04:04:53 +08:00
|
|
|
static void Run(void* arg) {
|
|
|
|
Callback* callback = reinterpret_cast<Callback*>(arg);
|
2019-09-11 02:09:31 +08:00
|
|
|
RunState* state = callback->state_;
|
|
|
|
|
|
|
|
MutexLock l(&state->mu);
|
2023-03-29 07:20:01 +08:00
|
|
|
ASSERT_EQ(state->last_id, callback->id_ - 1);
|
|
|
|
state->last_id = callback->id_;
|
2019-09-11 02:09:31 +08:00
|
|
|
state->cvar.Signal();
|
2011-03-19 06:37:00 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2019-09-11 02:09:31 +08:00
|
|
|
RunState state;
|
2023-03-29 07:20:01 +08:00
|
|
|
Callback callback1(&state, 1);
|
|
|
|
Callback callback2(&state, 2);
|
|
|
|
Callback callback3(&state, 3);
|
|
|
|
Callback callback4(&state, 4);
|
2019-03-12 04:04:53 +08:00
|
|
|
env_->Schedule(&Callback::Run, &callback1);
|
|
|
|
env_->Schedule(&Callback::Run, &callback2);
|
|
|
|
env_->Schedule(&Callback::Run, &callback3);
|
|
|
|
env_->Schedule(&Callback::Run, &callback4);
|
2011-03-19 06:37:00 +08:00
|
|
|
|
2019-09-11 02:09:31 +08:00
|
|
|
MutexLock l(&state.mu);
|
2023-03-29 07:20:01 +08:00
|
|
|
while (state.last_id != 4) {
|
2019-09-11 02:09:31 +08:00
|
|
|
state.cvar.Wait();
|
|
|
|
}
|
2011-03-19 06:37:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
struct State {
|
|
|
|
port::Mutex mu;
|
2019-09-11 02:09:31 +08:00
|
|
|
port::CondVar cvar{&mu};
|
|
|
|
|
2018-03-24 03:50:14 +08:00
|
|
|
int val GUARDED_BY(mu);
|
|
|
|
int num_running GUARDED_BY(mu);
|
|
|
|
|
2019-05-03 02:01:00 +08:00
|
|
|
State(int val, int num_running) : val(val), num_running(num_running) {}
|
2011-03-19 06:37:00 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static void ThreadBody(void* arg) {
|
|
|
|
State* s = reinterpret_cast<State*>(arg);
|
|
|
|
s->mu.Lock();
|
|
|
|
s->val += 1;
|
|
|
|
s->num_running -= 1;
|
2019-09-11 02:09:31 +08:00
|
|
|
s->cvar.Signal();
|
2011-03-19 06:37:00 +08:00
|
|
|
s->mu.Unlock();
|
|
|
|
}
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
TEST_F(EnvTest, StartThread) {
|
2018-03-24 03:50:14 +08:00
|
|
|
State state(0, 3);
|
2011-03-19 06:37:00 +08:00
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
env_->StartThread(&ThreadBody, &state);
|
|
|
|
}
|
2018-03-24 03:50:14 +08:00
|
|
|
|
|
|
|
MutexLock l(&state.mu);
|
2019-09-11 02:09:31 +08:00
|
|
|
while (state.num_running != 0) {
|
|
|
|
state.cvar.Wait();
|
|
|
|
}
|
2011-03-19 06:37:00 +08:00
|
|
|
ASSERT_EQ(state.val, 3);
|
|
|
|
}
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
TEST_F(EnvTest, TestOpenNonExistentFile) {
|
2017-07-11 04:32:58 +08:00
|
|
|
// Write some test data to a single file that will be opened |n| times.
|
|
|
|
std::string test_dir;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->GetTestDirectory(&test_dir));
|
2017-07-11 04:32:58 +08:00
|
|
|
|
|
|
|
std::string non_existent_file = test_dir + "/non_existent_file";
|
|
|
|
ASSERT_TRUE(!env_->FileExists(non_existent_file));
|
|
|
|
|
|
|
|
RandomAccessFile* random_access_file;
|
2019-05-03 02:01:00 +08:00
|
|
|
Status status =
|
|
|
|
env_->NewRandomAccessFile(non_existent_file, &random_access_file);
|
2023-03-29 05:37:48 +08:00
|
|
|
#if defined(LEVELDB_PLATFORM_CHROMIUM)
|
|
|
|
// TODO(crbug.com/760362): See comment in MakeIOError() from env_chromium.cc.
|
|
|
|
ASSERT_TRUE(status.IsIOError());
|
|
|
|
#else
|
2017-07-11 04:32:58 +08:00
|
|
|
ASSERT_TRUE(status.IsNotFound());
|
2023-03-29 05:37:48 +08:00
|
|
|
#endif // defined(LEVELDB_PLATFORM_CHROMIUM)
|
2017-07-11 04:32:58 +08:00
|
|
|
|
|
|
|
SequentialFile* sequential_file;
|
|
|
|
status = env_->NewSequentialFile(non_existent_file, &sequential_file);
|
2023-03-29 05:37:48 +08:00
|
|
|
#if defined(LEVELDB_PLATFORM_CHROMIUM)
|
|
|
|
// TODO(crbug.com/760362): See comment in MakeIOError() from env_chromium.cc.
|
|
|
|
ASSERT_TRUE(status.IsIOError());
|
|
|
|
#else
|
2017-07-11 04:32:58 +08:00
|
|
|
ASSERT_TRUE(status.IsNotFound());
|
2023-03-29 05:37:48 +08:00
|
|
|
#endif // defined(LEVELDB_PLATFORM_CHROMIUM)
|
2017-07-11 04:32:58 +08:00
|
|
|
}
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
TEST_F(EnvTest, ReopenWritableFile) {
|
2017-10-04 01:38:02 +08:00
|
|
|
std::string test_dir;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->GetTestDirectory(&test_dir));
|
2017-10-04 01:38:02 +08:00
|
|
|
std::string test_file_name = test_dir + "/reopen_writable_file.txt";
|
Add Env::Remove{File,Dir} which obsolete Env::Delete{File,Dir}.
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
2020-01-09 01:14:53 +08:00
|
|
|
env_->RemoveFile(test_file_name);
|
2017-10-04 01:38:02 +08:00
|
|
|
|
|
|
|
WritableFile* writable_file;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->NewWritableFile(test_file_name, &writable_file));
|
2017-10-04 01:38:02 +08:00
|
|
|
std::string data("hello world!");
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(writable_file->Append(data));
|
|
|
|
ASSERT_LEVELDB_OK(writable_file->Close());
|
2017-10-04 01:38:02 +08:00
|
|
|
delete writable_file;
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->NewWritableFile(test_file_name, &writable_file));
|
2017-10-04 01:38:02 +08:00
|
|
|
data = "42";
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(writable_file->Append(data));
|
|
|
|
ASSERT_LEVELDB_OK(writable_file->Close());
|
2017-10-04 01:38:02 +08:00
|
|
|
delete writable_file;
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(ReadFileToString(env_, test_file_name, &data));
|
2017-10-04 01:38:02 +08:00
|
|
|
ASSERT_EQ(std::string("42"), data);
|
Add Env::Remove{File,Dir} which obsolete Env::Delete{File,Dir}.
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
2020-01-09 01:14:53 +08:00
|
|
|
env_->RemoveFile(test_file_name);
|
2017-10-04 01:38:02 +08:00
|
|
|
}
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
TEST_F(EnvTest, ReopenAppendableFile) {
|
2017-10-04 01:38:02 +08:00
|
|
|
std::string test_dir;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->GetTestDirectory(&test_dir));
|
2017-10-04 01:38:02 +08:00
|
|
|
std::string test_file_name = test_dir + "/reopen_appendable_file.txt";
|
Add Env::Remove{File,Dir} which obsolete Env::Delete{File,Dir}.
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
2020-01-09 01:14:53 +08:00
|
|
|
env_->RemoveFile(test_file_name);
|
2017-10-04 01:38:02 +08:00
|
|
|
|
|
|
|
WritableFile* appendable_file;
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->NewAppendableFile(test_file_name, &appendable_file));
|
2017-10-04 01:38:02 +08:00
|
|
|
std::string data("hello world!");
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(appendable_file->Append(data));
|
|
|
|
ASSERT_LEVELDB_OK(appendable_file->Close());
|
2017-10-04 01:38:02 +08:00
|
|
|
delete appendable_file;
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(env_->NewAppendableFile(test_file_name, &appendable_file));
|
2017-10-04 01:38:02 +08:00
|
|
|
data = "42";
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(appendable_file->Append(data));
|
|
|
|
ASSERT_LEVELDB_OK(appendable_file->Close());
|
2017-10-04 01:38:02 +08:00
|
|
|
delete appendable_file;
|
|
|
|
|
2019-11-22 05:09:53 +08:00
|
|
|
ASSERT_LEVELDB_OK(ReadFileToString(env_, test_file_name, &data));
|
2017-10-04 01:38:02 +08:00
|
|
|
ASSERT_EQ(std::string("hello world!42"), data);
|
Add Env::Remove{File,Dir} which obsolete Env::Delete{File,Dir}.
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
2020-01-09 01:14:53 +08:00
|
|
|
env_->RemoveFile(test_file_name);
|
2017-10-04 01:38:02 +08:00
|
|
|
}
|
|
|
|
|
2011-11-01 01:22:06 +08:00
|
|
|
} // namespace leveldb
|