[ViewVC] Diff of: cvs/BDB/BDB.pm

Comparing BDB/BDB.pm (file contents):
Revision 1.15 by root, Thu Sep 13 21:34:00 2007 UTC vs.
Revision 1.22 by root, Mon Dec 10 03:57:27 2007 UTC

 BDB - Asynchronous Berkeley DB access
 =head1 SYNOPSIS
  use BDB;
+ my $env = db_env_create;
+ mkdir "bdtest", 0700;
+ db_env_open
+    $env,
+    "bdtest",
+    BDB::INIT_LOCK | BDB::INIT_LOG | BDB::INIT_MPOOL
+    | BDB::INIT_TXN | BDB::RECOVER | BDB::USE_ENVIRON | BDB::CREATE,
+    0600;
+ $env->set_flags (BDB::AUTO_COMMIT | BDB::TXN_NOSYNC, 1);
+ my $db = db_create $env;
+ db_open $db, undef, "table", undef, BDB::BTREE, BDB::AUTO_COMMIT | BDB::CREATE
+                                     | BDB::READ_UNCOMMITTED, 0600;
+ db_put $db, undef, "key", "data", 0, sub {
+    db_del $db, undef, "key";
+ };
+ db_sync $db;
+ # automatic result processing with AnyEvent:
+ our $FH; open $FH, "<&=" . BDB::poll_fileno;
+ our $WATCHER = AnyEvent->io (fh => $FH, poll => 'r', cb => \&BDB::poll_cb);
+ # automatic result processing with EV:
+ my $WATCHER = EV::io BDB::poll_fileno, EV::READ, \&BDB::poll_cb;
+ # with Glib:
+ add_watch Glib::IO BDB::poll_fileno,
+           in => sub { BDB::poll_cb; 1 };
+ # or simply flush manually
+ BDB::flush;
 =head1 DESCRIPTION
 See the BerkeleyDB documentation (L<http://www.oracle.com/technology/documentation/berkeley-db/db/index.html>).
 The BDB API is very similar to the C API (the translation has been very faithful).
 use strict 'vars';
 use base 'Exporter';
 BEGIN {
-   our $VERSION = '1.1';
+   our $VERSION = '1.3';
    our @BDB_REQ = qw(
       db_env_open db_env_close db_env_txn_checkpoint db_env_lock_detect
       db_env_memp_sync db_env_memp_trickle
       db_open db_close db_compact db_sync db_put db_get db_pget db_del db_key_range
 =head2 BERKELEYDB FUNCTIONS
 All of these are functions. The create functions simply return a new
 object and never block. All the remaining functions all take an optional
-callback as last argument. If it is missing, then the fucntion will be
+callback as last argument that gets passed the return value. If it is
-executed synchronously.
+missing, then the function will be executed synchronously, and the return
+value is returned as normally.
 BDB functions that cannot block (mostly functions that manipulate
 settings) are method calls on the relevant objects, so the rule of thumb
 is: if its a method, its not blocking, if its a function, it takes a
 callback as last argument.
    db_sequence_remove (DB_SEQUENCE *seq, DB_TXN_ornull *txnid = 0, U32 flags = 0, SV *callback = &PL_sv_undef)
       flags: TXN_NOSYNC
 =head4 db_txn_finish (DB_TXN *txn, U32 flags = 0, SV *callback = &PL_sv_undef)
-This is not a Berkeley DB function but a BDB module extension. It is very
+This is not actually a Berkeley DB function but a BDB module
+extension. The background for this exytension is: It is very annoying to
-annoying to have to check every single BDB function for error returns and
+have to check every single BDB function for error returns and provide a
-provide a codepath out of your transaction. While the BDB module still
+codepath out of your transaction. While the BDB module still makes this
-makes this possible, it contains the following extensions:
+possible, it contains the following extensions:
 When a transaction-protected function returns any operating system
 error (errno > 0), BDB will set the C<TXN_DEADLOCK> flag on the
-transaction. This flag is also set by Berkeley DB functions externally
+transaction. This flag is also set by Berkeley DB functions themselves
 when an operation fails with LOCK_DEADLOCK, and it causes all further
 operations on that transaction (including C<db_txn_commit>) to fail.
 The C<db_txn_finish> request will look at this flag, and, if it is set,
 will automatically call C<db_txn_abort> (setting errno to C<LOCK_DEADLOCK>
-if it isn't set). If it isn't set, it will call C<db_txn_commit> and
+if it isn't set to something else yet). If it isn't set, it will call
-return the error normally.
+C<db_txn_commit> and return the error normally.
 How to use this? Easy: just write your transaction normally:
    my $txn = $db_env->txn_begin;
    db_get $db, $txn, "key", my $data;
 That is, handle only the expected errors. If something unexpected happens
 (EIO, LOCK_NOTGRANTED or a deadlock in either db_get or db_put), then the remaining
 requests (db_put in this case) will simply be skipped (they will fail with
 LOCK_DEADLOCK) and the transaction will be aborted.
-You cna use the C<< $txn->failed >> method to check wether a transaction
+You can use the C<< $txn->failed >> method to check wether a transaction
 has failed in this way and abort further processing (excluding
 C<db_txn_finish>).
 =head3 DB_ENV/database environment methods
    $int = $env->set_lk_max_lockers (U32 max)
    $int = $env->set_lk_max_locks (U32 max)
    $int = $env->set_lk_max_objects (U32 max)
    $int = $env->set_lg_bsize (U32 max)
    $int = $env->set_lg_max (U32 max)
+   $int = $env->mutex_set_increment (U32 increment)
+   $int = $env->mutex_set_tas_spins (U32 tas_spins)
+   $int = $env->mutex_set_max (U32 max)
+   $int = $env->mutex_set_align (U32 align)
    $txn = $env->txn_begin (DB_TXN_ornull *parent = 0, U32 flags = 0)
       flags: READ_COMMITTED READ_UNCOMMITTED TXN_NOSYNC TXN_NOWAIT TXN_SNAPSHOT TXN_SYNC TXN_WAIT TXN_WRITE_NOSYNC
 =head4 Example:
 interactiveness when perl is not fast enough to process all requests in
 time.
 For interactive programs, values such as C<0.01> to C<0.1> should be fine.
-Example: Install an Event watcher that automatically calls
+Example: Install an EV watcher that automatically calls
 BDB::poll_cb with low priority, to ensure that other parts of the
-program get the CPU sometimes even under high AIO load.
+program get the CPU sometimes even under high load.
    # try not to spend much more than 0.1s in poll_cb
    BDB::max_poll_time 0.1;
-   # use a low priority so other tasks have priority
+   my $bdb_poll = EV::io BDB::poll_fileno, EV::READ, \&BDB::poll_cb);
-   Event->io (fd => BDB::poll_fileno,
-              poll => 'r', nice => 1,
-              cb => &BDB::poll_cb);
 =item BDB::poll_wait
 If there are any outstanding requests and none of them in the result
 phase, wait till the result filehandle becomes ready for reading (simply
    BDB::poll_wait, BDB::poll_cb
 =item BDB::flush
-Wait till all outstanding AIO requests have been handled.
+Wait till all outstanding BDB requests have been handled.
 Strictly equivalent to:
    BDB::poll_wait, BDB::poll_cb
       while BDB::nreqs;
 =over 4
 =item BDB::min_parallel $nthreads
-Set the minimum number of AIO threads to C<$nthreads>. The current
+Set the minimum number of BDB threads to C<$nthreads>. The current
 default is C<8>, which means eight asynchronous operations can execute
 concurrently at any one time (the number of outstanding requests,
 however, is unlimited).
-BDB starts threads only on demand, when an AIO request is queued and
+BDB starts threads only on demand, when an BDB request is queued and
 no free thread exists. Please note that queueing up a hundred requests can
 create demand for a hundred threads, even if it turns out that everything
 is in the cache and could have been processed faster by a single thread.
 It is recommended to keep the number of threads relatively low, as some
 Under most circumstances you don't need to call this function, as the
 module selects a default that is suitable for low to moderate load.
 =item BDB::max_parallel $nthreads
-Sets the maximum number of AIO threads to C<$nthreads>. If more than the
+Sets the maximum number of BDB threads to C<$nthreads>. If more than the
 specified number of threads are currently running, this function kills
 them. This function blocks until the limit is reached.
 While C<$nthreads> are zero, aio requests get queued but not executed
 until the number of threads has been increased again.
 =head2 FORK BEHAVIOUR
 This module should do "the right thing" when the process using it forks:
-Before the fork, IO::AIO enters a quiescent state where no requests
+Before the fork, BDB enters a quiescent state where no requests
 can be added in other threads and no results will be processed. After
 the fork the parent simply leaves the quiescent state and continues
 request/result processing, while the child frees the request/result queue
 (so that the requests started before the fork will only be handled in the
 parent). Threads will be started on demand until the limit set in the
 parent process has been reached again.
 In short: the parent will, after a short pause, continue as if fork had
-not been called, while the child will act as if IO::AIO has not been used
+not been called, while the child will act as if BDB has not been used
 yet.
 =head2 MEMORY USAGE
 Per-request usage:
    TXN_DEADLOCK flag will be set on the transaction. See C<db_txn_finish>,
    above.
 =head1 SEE ALSO
-L<Coro::AIO>.
+L<Coro::BDB>, L<IO::AIO>.
 =head1 AUTHOR
  Marc Lehmann <schmorp@schmorp.de>
  http://home.schmorp.de/

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing BDB/BDB.pm (file contents): Revision 1.15 by root, Thu Sep 13 21:34:00 2007 UTC vs. Revision 1.22 by root, Mon Dec 10 03:57:27 2007 UTC

Diff Legend

Comparing BDB/BDB.pm (file contents):
Revision 1.15 by root, Thu Sep 13 21:34:00 2007 UTC vs.
Revision 1.22 by root, Mon Dec 10 03:57:27 2007 UTC