小组成员:10215300402-朱维清 & 10222140408 谷杰
您最多选择25个主题 主题必须以字母或数字开头,可以包含连字符 (-),并且长度不得超过35个字符

417 行
16 KiB

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
5 年前
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
5 年前
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
5 年前
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
5 年前
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
5 年前
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
5 年前
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
5 年前
7 年前
Release 1.18 Changes are: * Update version number to 1.18 * Replace the basic fprintf call with a call to fwrite in order to work around the apparent compiler optimization/rewrite failure that we are seeing with the new toolchain/iOS SDKs provided with Xcode6 and iOS8. * Fix ALL the header guards. * Createed a README.md with the LevelDB project description. * A new CONTRIBUTING file. * Don't implicitly convert uint64_t to size_t or int. Either preserve it as uint64_t, or explicitly cast. This fixes MSVC warnings about possible value truncation when compiling this code in Chromium. * Added a DumpFile() library function that encapsulates the guts of the "leveldbutil dump" command. This will allow clients to dump data to their log files instead of stdout. It will also allow clients to supply their own environment. * leveldb: Remove unused function 'ConsumeChar'. * leveldbutil: Remove unused member variables from WriteBatchItemPrinter. * OpenBSD, NetBSD and DragonflyBSD have _LITTLE_ENDIAN, so define PLATFORM_IS_LITTLE_ENDIAN like on FreeBSD. This fixes: * issue #143 * issue #198 * issue #249 * Switch from <cstdatomic> to <atomic>. The former never made it into the standard and doesn't exist in modern gcc versions at all. The later contains everything that leveldb was using from the former. This problem was noticed when porting to Portable Native Client where no memory barrier is defined. The fact that <cstdatomic> is missing normally goes unnoticed since memory barriers are defined for most architectures. * Make Hash() treat its input as unsigned. Before this change LevelDB files from platforms with different signedness of char were not compatible. This change fixes: issue #243 * Verify checksums of index/meta/filter blocks when paranoid_checks set. * Invoke all tools for iOS with xcrun. (This was causing problems with the new XCode 5.1.1 image on pulse.) * include <sys/stat.h> only once, and fix the following linter warning: "Found C system header after C++ system header" * When encountering a corrupted table file, return Status::Corruption instead of Status::InvalidArgument. * Support cygwin as build platform, patch is from https://code.google.com/p/leveldb/issues/detail?id=188 * Fix typo, merge patch from https://code.google.com/p/leveldb/issues/detail?id=159 * Fix typos and comments, and address the following two issues: * issue #166 * issue #241 * Add missing db synchronize after "fillseq" in the benchmark. * Removed unused variable in SeekRandom: value (issue #201)
10 年前
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
5 年前
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
5 年前
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
5 年前
  1. // Copyright (c) 2011 The LevelDB Authors. All rights reserved.
  2. // Use of this source code is governed by a BSD-style license that can be
  3. // found in the LICENSE file. See the AUTHORS file for names of contributors.
  4. //
  5. // An Env is an interface used by the leveldb implementation to access
  6. // operating system functionality like the filesystem etc. Callers
  7. // may wish to provide a custom Env object when opening a database to
  8. // get fine gain control; e.g., to rate limit file system operations.
  9. //
  10. // All Env implementations are safe for concurrent access from
  11. // multiple threads without any external synchronization.
  12. #ifndef STORAGE_LEVELDB_INCLUDE_ENV_H_
  13. #define STORAGE_LEVELDB_INCLUDE_ENV_H_
  14. #include <cstdarg>
  15. #include <cstdint>
  16. #include <string>
  17. #include <vector>
  18. #include "leveldb/export.h"
  19. #include "leveldb/status.h"
  20. // This workaround can be removed when leveldb::Env::DeleteFile is removed.
  21. #if defined(_WIN32)
  22. // On Windows, the method name DeleteFile (below) introduces the risk of
  23. // triggering undefined behavior by exposing the compiler to different
  24. // declarations of the Env class in different translation units.
  25. //
  26. // This is because <windows.h>, a fairly popular header file for Windows
  27. // applications, defines a DeleteFile macro. So, files that include the Windows
  28. // header before this header will contain an altered Env declaration.
  29. //
  30. // This workaround ensures that the compiler sees the same Env declaration,
  31. // independently of whether <windows.h> was included.
  32. #if defined(DeleteFile)
  33. #undef DeleteFile
  34. #define LEVELDB_DELETEFILE_UNDEFINED
  35. #endif // defined(DeleteFile)
  36. #endif // defined(_WIN32)
  37. namespace leveldb {
  38. class FileLock;
  39. class Logger;
  40. class RandomAccessFile;
  41. class SequentialFile;
  42. class Slice;
  43. class WritableFile;
  44. class LEVELDB_EXPORT Env {
  45. public:
  46. Env();
  47. Env(const Env&) = delete;
  48. Env& operator=(const Env&) = delete;
  49. virtual ~Env();
  50. // Return a default environment suitable for the current operating
  51. // system. Sophisticated users may wish to provide their own Env
  52. // implementation instead of relying on this default environment.
  53. //
  54. // The result of Default() belongs to leveldb and must never be deleted.
  55. static Env* Default();
  56. // Create an object that sequentially reads the file with the specified name.
  57. // On success, stores a pointer to the new file in *result and returns OK.
  58. // On failure stores nullptr in *result and returns non-OK. If the file does
  59. // not exist, returns a non-OK status. Implementations should return a
  60. // NotFound status when the file does not exist.
  61. //
  62. // The returned file will only be accessed by one thread at a time.
  63. virtual Status NewSequentialFile(const std::string& fname,
  64. SequentialFile** result) = 0;
  65. // Create an object supporting random-access reads from the file with the
  66. // specified name. On success, stores a pointer to the new file in
  67. // *result and returns OK. On failure stores nullptr in *result and
  68. // returns non-OK. If the file does not exist, returns a non-OK
  69. // status. Implementations should return a NotFound status when the file does
  70. // not exist.
  71. //
  72. // The returned file may be concurrently accessed by multiple threads.
  73. virtual Status NewRandomAccessFile(const std::string& fname,
  74. RandomAccessFile** result) = 0;
  75. // Create an object that writes to a new file with the specified
  76. // name. Deletes any existing file with the same name and creates a
  77. // new file. On success, stores a pointer to the new file in
  78. // *result and returns OK. On failure stores nullptr in *result and
  79. // returns non-OK.
  80. //
  81. // The returned file will only be accessed by one thread at a time.
  82. virtual Status NewWritableFile(const std::string& fname,
  83. WritableFile** result) = 0;
  84. // Create an object that either appends to an existing file, or
  85. // writes to a new file (if the file does not exist to begin with).
  86. // On success, stores a pointer to the new file in *result and
  87. // returns OK. On failure stores nullptr in *result and returns
  88. // non-OK.
  89. //
  90. // The returned file will only be accessed by one thread at a time.
  91. //
  92. // May return an IsNotSupportedError error if this Env does
  93. // not allow appending to an existing file. Users of Env (including
  94. // the leveldb implementation) must be prepared to deal with
  95. // an Env that does not support appending.
  96. virtual Status NewAppendableFile(const std::string& fname,
  97. WritableFile** result);
  98. // Returns true iff the named file exists.
  99. virtual bool FileExists(const std::string& fname) = 0;
  100. // Store in *result the names of the children of the specified directory.
  101. // The names are relative to "dir".
  102. // Original contents of *results are dropped.
  103. virtual Status GetChildren(const std::string& dir,
  104. std::vector<std::string>* result) = 0;
  105. // Delete the named file.
  106. //
  107. // The default implementation calls DeleteFile, to support legacy Env
  108. // implementations. Updated Env implementations must override RemoveFile and
  109. // ignore the existence of DeleteFile. Updated code calling into the Env API
  110. // must call RemoveFile instead of DeleteFile.
  111. //
  112. // A future release will remove DeleteDir and the default implementation of
  113. // RemoveDir.
  114. virtual Status RemoveFile(const std::string& fname);
  115. // DEPRECATED: Modern Env implementations should override RemoveFile instead.
  116. //
  117. // The default implementation calls RemoveFile, to support legacy Env user
  118. // code that calls this method on modern Env implementations. Modern Env user
  119. // code should call RemoveFile.
  120. //
  121. // A future release will remove this method.
  122. virtual Status DeleteFile(const std::string& fname);
  123. // Create the specified directory.
  124. virtual Status CreateDir(const std::string& dirname) = 0;
  125. // Delete the specified directory.
  126. //
  127. // The default implementation calls DeleteDir, to support legacy Env
  128. // implementations. Updated Env implementations must override RemoveDir and
  129. // ignore the existence of DeleteDir. Modern code calling into the Env API
  130. // must call RemoveDir instead of DeleteDir.
  131. //
  132. // A future release will remove DeleteDir and the default implementation of
  133. // RemoveDir.
  134. virtual Status RemoveDir(const std::string& dirname);
  135. // DEPRECATED: Modern Env implementations should override RemoveDir instead.
  136. //
  137. // The default implementation calls RemoveDir, to support legacy Env user
  138. // code that calls this method on modern Env implementations. Modern Env user
  139. // code should call RemoveDir.
  140. //
  141. // A future release will remove this method.
  142. virtual Status DeleteDir(const std::string& dirname);
  143. // Store the size of fname in *file_size.
  144. virtual Status GetFileSize(const std::string& fname, uint64_t* file_size) = 0;
  145. // Rename file src to target.
  146. virtual Status RenameFile(const std::string& src,
  147. const std::string& target) = 0;
  148. // Lock the specified file. Used to prevent concurrent access to
  149. // the same db by multiple processes. On failure, stores nullptr in
  150. // *lock and returns non-OK.
  151. //
  152. // On success, stores a pointer to the object that represents the
  153. // acquired lock in *lock and returns OK. The caller should call
  154. // UnlockFile(*lock) to release the lock. If the process exits,
  155. // the lock will be automatically released.
  156. //
  157. // If somebody else already holds the lock, finishes immediately
  158. // with a failure. I.e., this call does not wait for existing locks
  159. // to go away.
  160. //
  161. // May create the named file if it does not already exist.
  162. virtual Status LockFile(const std::string& fname, FileLock** lock) = 0;
  163. // Release the lock acquired by a previous successful call to LockFile.
  164. // REQUIRES: lock was returned by a successful LockFile() call
  165. // REQUIRES: lock has not already been unlocked.
  166. virtual Status UnlockFile(FileLock* lock) = 0;
  167. // Arrange to run "(*function)(arg)" once in a background thread.
  168. //
  169. // "function" may run in an unspecified thread. Multiple functions
  170. // added to the same Env may run concurrently in different threads.
  171. // I.e., the caller may not assume that background work items are
  172. // serialized.
  173. virtual void Schedule(void (*function)(void* arg), void* arg) = 0;
  174. // Start a new thread, invoking "function(arg)" within the new thread.
  175. // When "function(arg)" returns, the thread will be destroyed.
  176. virtual void StartThread(void (*function)(void* arg), void* arg) = 0;
  177. // *path is set to a temporary directory that can be used for testing. It may
  178. // or may not have just been created. The directory may or may not differ
  179. // between runs of the same process, but subsequent calls will return the
  180. // same directory.
  181. virtual Status GetTestDirectory(std::string* path) = 0;
  182. // Create and return a log file for storing informational messages.
  183. virtual Status NewLogger(const std::string& fname, Logger** result) = 0;
  184. // Returns the number of micro-seconds since some fixed point in time. Only
  185. // useful for computing deltas of time.
  186. virtual uint64_t NowMicros() = 0;
  187. // Sleep/delay the thread for the prescribed number of micro-seconds.
  188. virtual void SleepForMicroseconds(int micros) = 0;
  189. };
  190. // A file abstraction for reading sequentially through a file
  191. class LEVELDB_EXPORT SequentialFile {
  192. public:
  193. SequentialFile() = default;
  194. SequentialFile(const SequentialFile&) = delete;
  195. SequentialFile& operator=(const SequentialFile&) = delete;
  196. virtual ~SequentialFile();
  197. // Read up to "n" bytes from the file. "scratch[0..n-1]" may be
  198. // written by this routine. Sets "*result" to the data that was
  199. // read (including if fewer than "n" bytes were successfully read).
  200. // May set "*result" to point at data in "scratch[0..n-1]", so
  201. // "scratch[0..n-1]" must be live when "*result" is used.
  202. // If an error was encountered, returns a non-OK status.
  203. //
  204. // REQUIRES: External synchronization
  205. virtual Status Read(size_t n, Slice* result, char* scratch) = 0;
  206. // Skip "n" bytes from the file. This is guaranteed to be no
  207. // slower that reading the same data, but may be faster.
  208. //
  209. // If end of file is reached, skipping will stop at the end of the
  210. // file, and Skip will return OK.
  211. //
  212. // REQUIRES: External synchronization
  213. virtual Status Skip(uint64_t n) = 0;
  214. };
  215. // A file abstraction for randomly reading the contents of a file.
  216. class LEVELDB_EXPORT RandomAccessFile {
  217. public:
  218. RandomAccessFile() = default;
  219. RandomAccessFile(const RandomAccessFile&) = delete;
  220. RandomAccessFile& operator=(const RandomAccessFile&) = delete;
  221. virtual ~RandomAccessFile();
  222. // Read up to "n" bytes from the file starting at "offset".
  223. // "scratch[0..n-1]" may be written by this routine. Sets "*result"
  224. // to the data that was read (including if fewer than "n" bytes were
  225. // successfully read). May set "*result" to point at data in
  226. // "scratch[0..n-1]", so "scratch[0..n-1]" must be live when
  227. // "*result" is used. If an error was encountered, returns a non-OK
  228. // status.
  229. //
  230. // Safe for concurrent use by multiple threads.
  231. virtual Status Read(uint64_t offset, size_t n, Slice* result,
  232. char* scratch) const = 0;
  233. };
  234. // A file abstraction for sequential writing. The implementation
  235. // must provide buffering since callers may append small fragments
  236. // at a time to the file.
  237. class LEVELDB_EXPORT WritableFile {
  238. public:
  239. WritableFile() = default;
  240. WritableFile(const WritableFile&) = delete;
  241. WritableFile& operator=(const WritableFile&) = delete;
  242. virtual ~WritableFile();
  243. virtual Status Append(const Slice& data) = 0;
  244. virtual Status Close() = 0;
  245. virtual Status Flush() = 0;
  246. virtual Status Sync() = 0;
  247. };
  248. // An interface for writing log messages.
  249. class LEVELDB_EXPORT Logger {
  250. public:
  251. Logger() = default;
  252. Logger(const Logger&) = delete;
  253. Logger& operator=(const Logger&) = delete;
  254. virtual ~Logger();
  255. // Write an entry to the log file with the specified format.
  256. virtual void Logv(const char* format, std::va_list ap) = 0;
  257. };
  258. // Identifies a locked file.
  259. class LEVELDB_EXPORT FileLock {
  260. public:
  261. FileLock() = default;
  262. FileLock(const FileLock&) = delete;
  263. FileLock& operator=(const FileLock&) = delete;
  264. virtual ~FileLock();
  265. };
  266. // Log the specified data to *info_log if info_log is non-null.
  267. void Log(Logger* info_log, const char* format, ...)
  268. #if defined(__GNUC__) || defined(__clang__)
  269. __attribute__((__format__(__printf__, 2, 3)))
  270. #endif
  271. ;
  272. // A utility routine: write "data" to the named file.
  273. LEVELDB_EXPORT Status WriteStringToFile(Env* env, const Slice& data,
  274. const std::string& fname);
  275. // A utility routine: read contents of named file into *data
  276. LEVELDB_EXPORT Status ReadFileToString(Env* env, const std::string& fname,
  277. std::string* data);
  278. // An implementation of Env that forwards all calls to another Env.
  279. // May be useful to clients who wish to override just part of the
  280. // functionality of another Env.
  281. class LEVELDB_EXPORT EnvWrapper : public Env {
  282. public:
  283. // Initialize an EnvWrapper that delegates all calls to *t.
  284. explicit EnvWrapper(Env* t) : target_(t) {}
  285. virtual ~EnvWrapper();
  286. // Return the target to which this Env forwards all calls.
  287. Env* target() const { return target_; }
  288. // The following text is boilerplate that forwards all methods to target().
  289. Status NewSequentialFile(const std::string& f, SequentialFile** r) override {
  290. return target_->NewSequentialFile(f, r);
  291. }
  292. Status NewRandomAccessFile(const std::string& f,
  293. RandomAccessFile** r) override {
  294. return target_->NewRandomAccessFile(f, r);
  295. }
  296. Status NewWritableFile(const std::string& f, WritableFile** r) override {
  297. return target_->NewWritableFile(f, r);
  298. }
  299. Status NewAppendableFile(const std::string& f, WritableFile** r) override {
  300. return target_->NewAppendableFile(f, r);
  301. }
  302. bool FileExists(const std::string& f) override {
  303. return target_->FileExists(f);
  304. }
  305. Status GetChildren(const std::string& dir,
  306. std::vector<std::string>* r) override {
  307. return target_->GetChildren(dir, r);
  308. }
  309. Status RemoveFile(const std::string& f) override {
  310. return target_->RemoveFile(f);
  311. }
  312. Status CreateDir(const std::string& d) override {
  313. return target_->CreateDir(d);
  314. }
  315. Status RemoveDir(const std::string& d) override {
  316. return target_->RemoveDir(d);
  317. }
  318. Status GetFileSize(const std::string& f, uint64_t* s) override {
  319. return target_->GetFileSize(f, s);
  320. }
  321. Status RenameFile(const std::string& s, const std::string& t) override {
  322. return target_->RenameFile(s, t);
  323. }
  324. Status LockFile(const std::string& f, FileLock** l) override {
  325. return target_->LockFile(f, l);
  326. }
  327. Status UnlockFile(FileLock* l) override { return target_->UnlockFile(l); }
  328. void Schedule(void (*f)(void*), void* a) override {
  329. return target_->Schedule(f, a);
  330. }
  331. void StartThread(void (*f)(void*), void* a) override {
  332. return target_->StartThread(f, a);
  333. }
  334. Status GetTestDirectory(std::string* path) override {
  335. return target_->GetTestDirectory(path);
  336. }
  337. Status NewLogger(const std::string& fname, Logger** result) override {
  338. return target_->NewLogger(fname, result);
  339. }
  340. uint64_t NowMicros() override { return target_->NowMicros(); }
  341. void SleepForMicroseconds(int micros) override {
  342. target_->SleepForMicroseconds(micros);
  343. }
  344. private:
  345. Env* target_;
  346. };
  347. } // namespace leveldb
  348. // This workaround can be removed when leveldb::Env::DeleteFile is removed.
  349. // Redefine DeleteFile if it was undefined earlier.
  350. #if defined(_WIN32) && defined(LEVELDB_DELETEFILE_UNDEFINED)
  351. #if defined(UNICODE)
  352. #define DeleteFile DeleteFileW
  353. #else
  354. #define DeleteFile DeleteFileA
  355. #endif // defined(UNICODE)
  356. #endif // defined(_WIN32) && defined(LEVELDB_DELETEFILE_UNDEFINED)
  357. #endif // STORAGE_LEVELDB_INCLUDE_ENV_H_