From 556ca85d43ac161292b35b171365f7945a00171a Mon Sep 17 00:00:00 2001 From: Joseph Wayne Norton Date: Sat, 29 Oct 2011 21:16:54 +0900 Subject: [PATCH] Update roadmap --- README.md | 35 +++++++++-------------------------- doc/README.md | 35 +++++++++-------------------------- doc/overview.edoc | 25 ++++--------------------- 3 files changed, 22 insertions(+), 73 deletions(-) diff --git a/README.md b/README.md index 98b2ba7..83d6714 100644 --- a/README.md +++ b/README.md @@ -585,35 +585,16 @@ Existing APIs (TBD) +
  • +

    +new/2 - + (http://code.google.com/p/leveldb/issues/detail?id=49) +

    • - - - -
    Sanjay Ghemawat
-View profile
- More options Sep 30, 1:04 am
-On Thu, Sep 29, 2011 at 8:30 AM, Joseph Wayne Norton wrote:
-> Hans -
-> Thanks.  Is is correct to assume that it is the caller's responsibility to
-> ensure this does not happen?
-
-leveldb guarantees that it will catch when two distinct processes
-try to open the db concurrently. However it doesn't guarantee what happens
-if the same process tries to do so and therefore it is the caller's
-responsibility
-to check for concurrent opens from the same process.
-This is ugly, but the unix file locking primitives are very annoying in
-this regard. I'll think about whether or not we should clean up the spec
-by doing extra checks inside the leveldb implementation.
    - - + + diff --git a/doc/README.md b/doc/README.md index fb857c8..915d346 100644 --- a/doc/README.md +++ b/doc/README.md @@ -585,35 +585,16 @@ Existing APIs (TBD) +
  • +

    +new/2 - + (http://code.google.com/p/leveldb/issues/detail?id=49) +

    • - - - -
    Sanjay Ghemawat
-View profile
- More options Sep 30, 1:04 am
-On Thu, Sep 29, 2011 at 8:30 AM, Joseph Wayne Norton wrote:
-> Hans -
-> Thanks.  Is is correct to assume that it is the caller's responsibility to
-> ensure this does not happen?
-
-leveldb guarantees that it will catch when two distinct processes
-try to open the db concurrently. However it doesn't guarantee what happens
-if the same process tries to do so and therefore it is the caller's
-responsibility
-to check for concurrent opens from the same process.
-This is ugly, but the unix file locking primitives are very annoying in
-this regard. I'll think about whether or not we should clean up the spec
-by doing extra checks inside the leveldb implementation.
    - - + + diff --git a/doc/overview.edoc b/doc/overview.edoc index 96fe7b9..a707699 100644 --- a/doc/overview.edoc +++ b/doc/overview.edoc @@ -282,28 +282,11 @@ $ erl -smp +A 5 -pz ../../sext/ebin -pz ../../qc/ebin (http://code.google.com/p/leveldb/issues/detail?id=43) - Existing APIs (TBD) - * +new/2+ - automatically detect and prevent multiple callers of the - same Erlang virtual machine from simultaneously opening the same - LevelDB. Excerpt from the Google leveldb mailing list: - + ------- -Sanjay Ghemawat -View profile - More options Sep 30, 1:04 am -On Thu, Sep 29, 2011 at 8:30 AM, Joseph Wayne Norton wrote: -> Hans - -> Thanks. Is is correct to assume that it is the caller's responsibility to -> ensure this does not happen? + * +delete/1+ + (http://code.google.com/p/leveldb/issues/detail?id=48) -leveldb guarantees that it will catch when two distinct processes -try to open the db concurrently. However it doesn't guarantee what happens -if the same process tries to do so and therefore it is the caller's -responsibility -to check for concurrent opens from the same process. -This is ugly, but the unix file locking primitives are very annoying in -this regard. I'll think about whether or not we should clean up the spec -by doing extra checks inside the leveldb implementation. ------- + * +new/2+ - + (http://code.google.com/p/leveldb/issues/detail?id=49) * +new/2+ - investigate if LevelDB\'s snapshot feature is useful (or not) for LETS