lmdb 0.5.3 → 0.6.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c02c1c99b143e331bf5fdbae711a57c4845b32ca07c4c041c9c639b96cbb8388
-  data.tar.gz: ce305105acf85f4161e654dc80ad045baeded4e8a8e39f45fed9f8da68f5c2ce
+  metadata.gz: d6f0a0943419dca02f5aab8971d28fe32b5771842cbfcb467e6f6c4b368aae4f
+  data.tar.gz: 5cd32d2a3b594861d92cfd9dcdd71aed3534b2ea7c4d910b3ce02e07dbb2ba02
 SHA512:
-  metadata.gz: 1303411d1515bf39a6406540f3a10d9e12c2bd3fea597d17a9e2b949bcf7707244381467a624edd15fada41ac65ae87721c2e42a9ec4dadb5b37e9f8db2a55b0
-  data.tar.gz: aeaa5861dcbde41e9fec9634f6cae749dce6a1348ab9541f90247c2cff60dcb10180701348757a00ba7fc11e93431ef97cfb3064e5face3cc50c704498ca183d
+  metadata.gz: 340922f5163f227adffd8ef78dfd7348ad159f86df16fb469e18d92a1f04b08a5769c867d03fe6610e291375fb8c515e86847f171db2552262338b91327eaa03
+  data.tar.gz: c99c4423232109007ac971ec2d268ea4642751f0d4bcda3aa91c69c9348371d88e0612439fd583f07ef3d5165d7fd384ffc85c3674cf2d372d559aa3dfdccabe

data/CONTRIBUTORS

@@ -5,3 +5,4 @@ Julien Ammous <schmurfy@gmail.com>
 Nathaniel Pierce <nwpierce@gmail.com>
 Richard Golding <golding@chrysaetos.org>
 Joel VanderWerf <vjoel@users.sourceforge.net>
+Dorian Taylor <code@doriantaylor.com>

data/Rakefile

@@ -7,12 +7,21 @@ PRJ = File.basename(GEMSPEC, ".gemspec")
 require 'bundler/setup'
 require 'rspec/core/rake_task'
 require 'rake/extensiontask'
+require 'ruby_memcheck'
+require 'ruby_memcheck/rspec/rake_task'
+
+RubyMemcheck.config(binary_name: 'lmdb_ext')
 
 RSpec::Core::RakeTask.new :spec
 Rake::ExtensionTask.new :lmdb_ext
 
+
 task :default => [:compile, :spec]
 
+namespace :spec do
+  RubyMemcheck::RSpec::RakeTask.new(valgrind: :compile)
+end
+
 def version
   @version ||= begin
     require "#{PRJ}/version"

data/behaviour.org

@@ -0,0 +1,35 @@
+#+STARTUP: showall hidestars
+* the situtation
+  - lmdb has two kinds of transaction: read-write and read-only
+  - there are two properties associated with transactions:
+    - nesting
+    - multiplicity
+  - *read-write* transactions can nest, but there can only be one stack of read-write transactions per *database*, that is, amongst /all/ threads and all processes attached to the persitent storage.
+  - *read-only* transactions /cannot/ nest (because it's not meaningful for a read-only transaction to nest), but there can be a read-only transaction per thread (and of course multiple threads per process).
+    - (i can't remember if you can have a thread with a read-write *and* read-only transaction going but we can probably assume not)
+  - so therefore we need a way to distinguish between read-write and read-only as well as identify the thread /across processes/ that has the one read-write transaction open.
+* undocumented behaviour
+** ~mdb_txn_begin~
+   - if the environment is read-only and the transaction is read-write, returns ~EACCES~
+   - if there is a parent transaction and the current transaction's flags are ~MDB_RDONLY~ or ~MDB_WRITEMAP~ (?) or ~TXN_BLOCKED~
+     - if the *parent's* transaction is ~MDB_TXN_RDONLY~ (which is the same as ~MDB_RDONLY~), return ~EINVAL~
+       - that's saying "read-only transactions can't be nested"
+     - otherwise, return ~MDB_BAD_TXN~
+       - this is saying "read-only transactions can't be children of read-write parents"
+   - otherwise a few boring scenarios where the function may return ~ENOMEM~
+   - otherwise check ~mdb_cursor_shadow~ or ~mdb_txn_renew0~
+   - XXX does ~mdb_txn_begin~ block when waiting for the read-write??
+* desired behaviour
+** ruby interface
+   - when the ruby programmer opens a read-only transaction within a read-only transaction, this should be a noop
+     - don't push any stack, don't allocate any resources, just do nothing
+   - when the ruby programmer opens a read-only transaction within a read-/write/ transaction, this should raise an exception
+     - in practice there's no harm except that this is more about communicating the right thing to the ruby programmer
+       - do we warn?
+   - problem: there's no way to know (via the lmdb api) if another process has a read-write transaction open
+     - poll?
+       - actually no it probably doesn't matter (the mdb api blocks anyway?)
+       - /actually/ actually, the cursed-ass goto pseudo-loop containing the ~CALL_WITHOUT_GVL~ deals with that
+** internal implementation
+   - a successfully-created read-write transaction has to set ~rw_txn_thread~ to the current thread (unless it is a sub-transaction in which case noop)
+   - when a read-write transaction is committed or aborted, ~rw_txn_thread~ has to be set back to null (unless the transaction has a parent)

data/ext/lmdb_ext/extconf.rb

@@ -1,13 +1,18 @@
 require 'mkmf'
 
 $CFLAGS = '-std=c99 -Wall -g'
+$CFLAGS << ' -fdeclspec' if /darwin/.match? RUBY_PLATFORM
 
 # Embed lmdb if we cannot find it
 if enable_config("bundled-lmdb", false) || !(find_header('lmdb.h') && have_library('lmdb', 'mdb_env_create'))
-  $INCFLAGS << " -I$(srcdir)/liblmdb"
+  lmdbpath = "../../vendor/libraries/liblmdb"
+  $INCFLAGS << " -I$(srcdir)/#{lmdbpath}"
   $VPATH ||= []
-  $VPATH << "$(srcdir)/liblmdb"
-  $srcs = Dir.glob("#{$srcdir}/{,liblmdb/}*.c").map {|n| File.basename(n) }
+  $VPATH << "$(srcdir)/#{lmdbpath}"
+  # XXX this is a sketchy, sketchy way to do this
+  $srcs = Dir.glob("#{$srcdir}/{#{lmdbpath}/{mdb,midl}.c,*.c}").map do |n|
+    File.basename(n)
+  end
 end
 
 have_header 'limits.h'