| 1 |
NAME |
| 2 |
BDB - Asynchronous Berkeley DB access |
| 3 |
|
| 4 |
SYNOPSIS |
| 5 |
use BDB; |
| 6 |
|
| 7 |
my $env = db_env_create; |
| 8 |
|
| 9 |
mkdir "bdtest", 0700; |
| 10 |
db_env_open |
| 11 |
$env, |
| 12 |
"bdtest", |
| 13 |
BDB::INIT_LOCK | BDB::INIT_LOG | BDB::INIT_MPOOL |
| 14 |
| BDB::INIT_TXN | BDB::RECOVER | BDB::USE_ENVIRON | BDB::CREATE, |
| 15 |
0600; |
| 16 |
|
| 17 |
$env->set_flags (BDB::AUTO_COMMIT | BDB::TXN_NOSYNC, 1); |
| 18 |
|
| 19 |
my $db = db_create $env; |
| 20 |
db_open $db, undef, "table", undef, BDB::BTREE, BDB::AUTO_COMMIT | BDB::CREATE |
| 21 |
| BDB::READ_UNCOMMITTED, 0600; |
| 22 |
db_put $db, undef, "key", "data", 0, sub { |
| 23 |
db_del $db, undef, "key"; |
| 24 |
}; |
| 25 |
db_sync $db; |
| 26 |
|
| 27 |
# when you also use Coro, management is easy: |
| 28 |
use Coro::BDB; |
| 29 |
|
| 30 |
# automatic result processing with AnyEvent: |
| 31 |
our $FH; open $FH, "<&=" . BDB::poll_fileno; |
| 32 |
our $WATCHER = AnyEvent->io (fh => $FH, poll => 'r', cb => \&BDB::poll_cb); |
| 33 |
|
| 34 |
# automatic result processing with EV: |
| 35 |
my $WATCHER = EV::io BDB::poll_fileno, EV::READ, \&BDB::poll_cb; |
| 36 |
|
| 37 |
# with Glib: |
| 38 |
add_watch Glib::IO BDB::poll_fileno, |
| 39 |
in => sub { BDB::poll_cb; 1 }; |
| 40 |
|
| 41 |
# or simply flush manually |
| 42 |
BDB::flush; |
| 43 |
|
| 44 |
DESCRIPTION |
| 45 |
See the BerkeleyDB documentation |
| 46 |
(<http://www.oracle.com/technology/documentation/berkeley-db/db/index.ht |
| 47 |
ml>). The BDB API is very similar to the C API (the translation has been |
| 48 |
very faithful). |
| 49 |
|
| 50 |
See also the example sections in the document below and possibly the eg/ |
| 51 |
subdirectory of the BDB distribution. Last not least see the IO::AIO |
| 52 |
documentation, as that module uses almost the same asynchronous request |
| 53 |
model as this module. |
| 54 |
|
| 55 |
I know this is woefully inadequate documentation. Send a patch! |
| 56 |
|
| 57 |
REQUEST ANATOMY AND LIFETIME |
| 58 |
Every request method creates a request. which is a C data structure not |
| 59 |
directly visible to Perl. |
| 60 |
|
| 61 |
During their existance, bdb requests travel through the following |
| 62 |
states, in order: |
| 63 |
|
| 64 |
ready |
| 65 |
Immediately after a request is created it is put into the ready |
| 66 |
state, waiting for a thread to execute it. |
| 67 |
|
| 68 |
execute |
| 69 |
A thread has accepted the request for processing and is currently |
| 70 |
executing it (e.g. blocking in read). |
| 71 |
|
| 72 |
pending |
| 73 |
The request has been executed and is waiting for result processing. |
| 74 |
|
| 75 |
While request submission and execution is fully asynchronous, result |
| 76 |
processing is not and relies on the perl interpreter calling |
| 77 |
"poll_cb" (or another function with the same effect). |
| 78 |
|
| 79 |
result |
| 80 |
The request results are processed synchronously by "poll_cb". |
| 81 |
|
| 82 |
The "poll_cb" function will process all outstanding aio requests by |
| 83 |
calling their callbacks, freeing memory associated with them and |
| 84 |
managing any groups they are contained in. |
| 85 |
|
| 86 |
done |
| 87 |
Request has reached the end of its lifetime and holds no resources |
| 88 |
anymore (except possibly for the Perl object, but its connection to |
| 89 |
the actual aio request is severed and calling its methods will |
| 90 |
either do nothing or result in a runtime error). |
| 91 |
|
| 92 |
FILENAMES/DATABASE NAMES |
| 93 |
The BDB expects "binary" filenames (octet strings) for pathnames on |
| 94 |
POSIX systems, and "unicode" filenames (strings with characters |
| 95 |
potentially >255) on Win32 (expecting a Unicode win32 build - win32 is a |
| 96 |
total mess). |
| 97 |
|
| 98 |
BERKELEYDB FUNCTIONS |
| 99 |
All of these are functions. The create functions simply return a new |
| 100 |
object and never block. All the remaining functions take an optional |
| 101 |
callback as last argument. If it is missing, then the function will be |
| 102 |
executed synchronously. In both cases, $! will reflect the return value |
| 103 |
of the function. |
| 104 |
|
| 105 |
BDB functions that cannot block (mostly functions that manipulate |
| 106 |
settings) are method calls on the relevant objects, so the rule of thumb |
| 107 |
is: if it's a method, it's not blocking, if it's a function, it takes a |
| 108 |
callback as last argument. |
| 109 |
|
| 110 |
In the following, $int signifies an integer return value, "octetstring" |
| 111 |
is a "binary string" (i.e. a perl string with no character indices |
| 112 |
>255), "U32" is an unsigned 32 bit integer, "int" is some integer, "NV" |
| 113 |
is a floating point value. |
| 114 |
|
| 115 |
The "SV *" types are generic perl scalars (for input and output of data |
| 116 |
values), and the "SV *callback" is the optional callback function to |
| 117 |
call when the request is completed. |
| 118 |
|
| 119 |
The various "DB_ENV" etc. arguments are handles return by |
| 120 |
"db_env_create", "db_create", "txn_begin" and so on. If they have an |
| 121 |
appended "_ornull" this means they are optional and you can pass "undef" |
| 122 |
for them, resulting a NULL pointer on the C level. |
| 123 |
|
| 124 |
BDB functions |
| 125 |
Functions in the BDB namespace, exported by default: |
| 126 |
|
| 127 |
$env = db_env_create (U32 env_flags = 0) |
| 128 |
flags: RPCCLIENT |
| 129 |
|
| 130 |
db_env_open (DB_ENV *env, octetstring db_home, U32 open_flags, int mode, SV *callback = &PL_sv_undef) |
| 131 |
open_flags: INIT_CDB INIT_LOCK INIT_LOG INIT_MPOOL INIT_REP INIT_TXN RECOVER RECOVER_FATAL USE_ENVIRON USE_ENVIRON_ROOT CREATE LOCKDOWN PRIVATE REGISTER SYSTEM_MEM |
| 132 |
db_env_close (DB_ENV *env, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 133 |
db_env_txn_checkpoint (DB_ENV *env, U32 kbyte = 0, U32 min = 0, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 134 |
flags: FORCE |
| 135 |
db_env_lock_detect (DB_ENV *env, U32 flags = 0, U32 atype = DB_LOCK_DEFAULT, SV *dummy = 0, SV *callback = &PL_sv_undef) |
| 136 |
atype: LOCK_DEFAULT LOCK_EXPIRE LOCK_MAXLOCKS LOCK_MAXWRITE LOCK_MINLOCKS LOCK_MINWRITE LOCK_OLDEST LOCK_RANDOM LOCK_YOUNGEST |
| 137 |
db_env_memp_sync (DB_ENV *env, SV *dummy = 0, SV *callback = &PL_sv_undef) |
| 138 |
db_env_memp_trickle (DB_ENV *env, int percent, SV *dummy = 0, SV *callback = &PL_sv_undef) |
| 139 |
|
| 140 |
$db = db_create (DB_ENV *env = 0, U32 flags = 0) |
| 141 |
flags: XA_CREATE |
| 142 |
|
| 143 |
db_open (DB *db, DB_TXN_ornull *txnid, octetstring file, octetstring database, int type, U32 flags, int mode, SV *callback = &PL_sv_undef) |
| 144 |
flags: AUTO_COMMIT CREATE EXCL MULTIVERSION NOMMAP RDONLY READ_UNCOMMITTED THREAD TRUNCATE |
| 145 |
db_close (DB *db, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 146 |
flags: DB_NOSYNC |
| 147 |
db_upgrade (DB *db, octetstring file, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 148 |
db_compact (DB *db, DB_TXN_ornull *txn = 0, SV *start = 0, SV *stop = 0, SV *unused1 = 0, U32 flags = DB_FREE_SPACE, SV *unused2 = 0, SV *callback = &PL_sv_undef) |
| 149 |
flags: FREELIST_ONLY FREE_SPACE |
| 150 |
db_sync (DB *db, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 151 |
db_key_range (DB *db, DB_TXN_ornull *txn, SV *key, SV *key_range, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 152 |
db_put (DB *db, DB_TXN_ornull *txn, SV *key, SV *data, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 153 |
flags: APPEND NODUPDATA NOOVERWRITE |
| 154 |
db_get (DB *db, DB_TXN_ornull *txn, SV *key, SV *data, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 155 |
flags: CONSUME CONSUME_WAIT GET_BOTH SET_RECNO MULTIPLE READ_COMMITTED READ_UNCOMMITTED RMW |
| 156 |
db_pget (DB *db, DB_TXN_ornull *txn, SV *key, SV *pkey, SV *data, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 157 |
flags: CONSUME CONSUME_WAIT GET_BOTH SET_RECNO MULTIPLE READ_COMMITTED READ_UNCOMMITTED RMW |
| 158 |
db_del (DB *db, DB_TXN_ornull *txn, SV *key, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 159 |
db_txn_commit (DB_TXN *txn, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 160 |
flags: TXN_NOSYNC TXN_SYNC |
| 161 |
db_txn_abort (DB_TXN *txn, SV *callback = &PL_sv_undef) |
| 162 |
|
| 163 |
db_c_close (DBC *dbc, SV *callback = &PL_sv_undef) |
| 164 |
db_c_count (DBC *dbc, SV *count, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 165 |
db_c_put (DBC *dbc, SV *key, SV *data, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 166 |
flags: AFTER BEFORE CURRENT KEYFIRST KEYLAST NODUPDATA |
| 167 |
db_c_get (DBC *dbc, SV *key, SV *data, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 168 |
flags: CURRENT FIRST GET_BOTH GET_BOTH_RANGE GET_RECNO JOIN_ITEM LAST NEXT NEXT_DUP NEXT_NODUP PREV PREV_DUP PREV_NODUP SET SET_RANGE SET_RECNO READ_UNCOMMITTED MULTIPLE MULTIPLE_KEY RMW |
| 169 |
db_c_pget (DBC *dbc, SV *key, SV *pkey, SV *data, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 170 |
db_c_del (DBC *dbc, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 171 |
|
| 172 |
db_sequence_open (DB_SEQUENCE *seq, DB_TXN_ornull *txnid, SV *key, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 173 |
flags: CREATE EXCL |
| 174 |
db_sequence_close (DB_SEQUENCE *seq, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 175 |
db_sequence_get (DB_SEQUENCE *seq, DB_TXN_ornull *txnid, int delta, SV *seq_value, U32 flags = DB_TXN_NOSYNC, SV *callback = &PL_sv_undef) |
| 176 |
flags: TXN_NOSYNC |
| 177 |
db_sequence_remove (DB_SEQUENCE *seq, DB_TXN_ornull *txnid = 0, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 178 |
flags: TXN_NOSYNC |
| 179 |
|
| 180 |
db_txn_finish (DB_TXN *txn, U32 flags = 0, SV *callback = &PL_sv_undef) |
| 181 |
This is not actually a Berkeley DB function but a BDB module extension. |
| 182 |
The background for this exytension is: It is very annoying to have to |
| 183 |
check every single BDB function for error returns and provide a codepath |
| 184 |
out of your transaction. While the BDB module still makes this possible, |
| 185 |
it contains the following extensions: |
| 186 |
|
| 187 |
When a transaction-protected function returns any operating system error |
| 188 |
(errno > 0), BDB will set the "TXN_DEADLOCK" flag on the transaction. |
| 189 |
This flag is also set by Berkeley DB functions themselves when an |
| 190 |
operation fails with LOCK_DEADLOCK, and it causes all further operations |
| 191 |
on that transaction (including "db_txn_commit") to fail. |
| 192 |
|
| 193 |
The "db_txn_finish" request will look at this flag, and, if it is set, |
| 194 |
will automatically call "db_txn_abort" (setting errno to "LOCK_DEADLOCK" |
| 195 |
if it isn't set to something else yet). If it isn't set, it will call |
| 196 |
"db_txn_commit" and return the error normally. |
| 197 |
|
| 198 |
How to use this? Easy: just write your transaction normally: |
| 199 |
|
| 200 |
my $txn = $db_env->txn_begin; |
| 201 |
db_get $db, $txn, "key", my $data; |
| 202 |
db_put $db, $txn, "key", $data + 1 unless $! == BDB::NOTFOUND; |
| 203 |
db_txn_finish $txn; |
| 204 |
die "transaction failed" if $!; |
| 205 |
|
| 206 |
That is, handle only the expected errors. If something unexpected |
| 207 |
happens (EIO, LOCK_NOTGRANTED or a deadlock in either db_get or db_put), |
| 208 |
then the remaining requests (db_put in this case) will simply be skipped |
| 209 |
(they will fail with LOCK_DEADLOCK) and the transaction will be aborted. |
| 210 |
|
| 211 |
You can use the "$txn->failed" method to check wether a transaction has |
| 212 |
failed in this way and abort further processing (excluding |
| 213 |
"db_txn_finish"). |
| 214 |
|
| 215 |
DB_ENV/database environment methods |
| 216 |
Methods available on DB_ENV/$env handles: |
| 217 |
|
| 218 |
DESTROY (DB_ENV_ornull *env) |
| 219 |
CODE: |
| 220 |
if (env) |
| 221 |
env->close (env, 0); |
| 222 |
|
| 223 |
$int = $env->set_data_dir (const char *dir) |
| 224 |
$int = $env->set_tmp_dir (const char *dir) |
| 225 |
$int = $env->set_lg_dir (const char *dir) |
| 226 |
$int = $env->set_shm_key (long shm_key) |
| 227 |
$int = $env->set_cachesize (U32 gbytes, U32 bytes, int ncache = 0) |
| 228 |
$int = $env->set_flags (U32 flags, int onoff) |
| 229 |
$env->set_errfile (FILE *errfile = 0) |
| 230 |
$env->set_msgfile (FILE *msgfile = 0) |
| 231 |
$int = $env->set_verbose (U32 which, int onoff = 1) |
| 232 |
$int = $env->set_encrypt (const char *password, U32 flags = 0) |
| 233 |
$int = $env->set_timeout (NV timeout_seconds, U32 flags = SET_TXN_TIMEOUT) |
| 234 |
$int = $env->set_mp_max_openfd (int maxopenfd); |
| 235 |
$int = $env->set_mp_max_write (int maxwrite, int maxwrite_sleep); |
| 236 |
$int = $env->set_mp_mmapsize (int mmapsize_mb) |
| 237 |
$int = $env->set_lk_detect (U32 detect = DB_LOCK_DEFAULT) |
| 238 |
$int = $env->set_lk_max_lockers (U32 max) |
| 239 |
$int = $env->set_lk_max_locks (U32 max) |
| 240 |
$int = $env->set_lk_max_objects (U32 max) |
| 241 |
$int = $env->set_lg_bsize (U32 max) |
| 242 |
$int = $env->set_lg_max (U32 max) |
| 243 |
$int = $env->mutex_set_increment (U32 increment) |
| 244 |
$int = $env->mutex_set_tas_spins (U32 tas_spins) |
| 245 |
$int = $env->mutex_set_max (U32 max) |
| 246 |
$int = $env->mutex_set_align (U32 align) |
| 247 |
|
| 248 |
$txn = $env->txn_begin (DB_TXN_ornull *parent = 0, U32 flags = 0) |
| 249 |
flags: READ_COMMITTED READ_UNCOMMITTED TXN_NOSYNC TXN_NOWAIT TXN_SNAPSHOT TXN_SYNC TXN_WAIT TXN_WRITE_NOSYNC |
| 250 |
|
| 251 |
Example: |
| 252 |
use AnyEvent; |
| 253 |
use BDB; |
| 254 |
|
| 255 |
our $FH; open $FH, "<&=" . BDB::poll_fileno; |
| 256 |
our $WATCHER = AnyEvent->io (fh => $FH, poll => 'r', cb => \&BDB::poll_cb); |
| 257 |
|
| 258 |
BDB::min_parallel 8; |
| 259 |
|
| 260 |
my $env = db_env_create; |
| 261 |
|
| 262 |
mkdir "bdtest", 0700; |
| 263 |
db_env_open |
| 264 |
$env, |
| 265 |
"bdtest", |
| 266 |
BDB::INIT_LOCK | BDB::INIT_LOG | BDB::INIT_MPOOL | BDB::INIT_TXN | BDB::RECOVER | BDB::USE_ENVIRON | BDB::CREATE, |
| 267 |
0600; |
| 268 |
|
| 269 |
$env->set_flags (BDB::AUTO_COMMIT | BDB::TXN_NOSYNC, 1); |
| 270 |
|
| 271 |
DB/database methods |
| 272 |
Methods available on DB/$db handles: |
| 273 |
|
| 274 |
DESTROY (DB_ornull *db) |
| 275 |
CODE: |
| 276 |
if (db) |
| 277 |
{ |
| 278 |
SV *env = (SV *)db->app_private; |
| 279 |
db->close (db, 0); |
| 280 |
SvREFCNT_dec (env); |
| 281 |
} |
| 282 |
|
| 283 |
$int = $db->set_cachesize (U32 gbytes, U32 bytes, int ncache = 0) |
| 284 |
$int = $db->set_flags (U32 flags) |
| 285 |
flags: CHKSUM ENCRYPT TXN_NOT_DURABLE |
| 286 |
Btree: DUP DUPSORT RECNUM REVSPLITOFF |
| 287 |
Hash: DUP DUPSORT |
| 288 |
Queue: INORDER |
| 289 |
Recno: RENUMBER SNAPSHOT |
| 290 |
|
| 291 |
$int = $db->set_encrypt (const char *password, U32 flags) |
| 292 |
$int = $db->set_lorder (int lorder) |
| 293 |
$int = $db->set_bt_minkey (U32 minkey) |
| 294 |
$int = $db->set_re_delim (int delim) |
| 295 |
$int = $db->set_re_pad (int re_pad) |
| 296 |
$int = $db->set_re_source (char *source) |
| 297 |
$int = $db->set_re_len (U32 re_len) |
| 298 |
$int = $db->set_h_ffactor (U32 h_ffactor) |
| 299 |
$int = $db->set_h_nelem (U32 h_nelem) |
| 300 |
$int = $db->set_q_extentsize (U32 extentsize) |
| 301 |
|
| 302 |
$dbc = $db->cursor (DB_TXN_ornull *txn = 0, U32 flags = 0) |
| 303 |
flags: READ_COMMITTED READ_UNCOMMITTED WRITECURSOR TXN_SNAPSHOT |
| 304 |
$seq = $db->sequence (U32 flags = 0) |
| 305 |
|
| 306 |
Example: |
| 307 |
my $db = db_create $env; |
| 308 |
db_open $db, undef, "table", undef, BDB::BTREE, BDB::AUTO_COMMIT | BDB::CREATE | BDB::READ_UNCOMMITTED, 0600; |
| 309 |
|
| 310 |
for (1..1000) { |
| 311 |
db_put $db, undef, "key $_", "data $_"; |
| 312 |
|
| 313 |
db_key_range $db, undef, "key $_", my $keyrange; |
| 314 |
my ($lt, $eq, $gt) = @$keyrange; |
| 315 |
} |
| 316 |
|
| 317 |
db_del $db, undef, "key $_" for 1..1000; |
| 318 |
|
| 319 |
db_sync $db; |
| 320 |
|
| 321 |
DB_TXN/transaction methods |
| 322 |
Methods available on DB_TXN/$txn handles: |
| 323 |
|
| 324 |
DESTROY (DB_TXN_ornull *txn) |
| 325 |
CODE: |
| 326 |
if (txn) |
| 327 |
txn->abort (txn); |
| 328 |
|
| 329 |
$int = $txn->set_timeout (NV timeout_seconds, U32 flags = SET_TXN_TIMEOUT) |
| 330 |
flags: SET_LOCK_TIMEOUT SET_TXN_TIMEOUT |
| 331 |
|
| 332 |
$bool = $txn->failed |
| 333 |
# see db_txn_finish documentation, above |
| 334 |
|
| 335 |
DBC/cursor methods |
| 336 |
Methods available on DBC/$dbc handles: |
| 337 |
|
| 338 |
DESTROY (DBC_ornull *dbc) |
| 339 |
CODE: |
| 340 |
if (dbc) |
| 341 |
dbc->c_close (dbc); |
| 342 |
|
| 343 |
$int = $cursor->set_priority ($priority = PRIORITY_*) |
| 344 |
|
| 345 |
Example: |
| 346 |
my $c = $db->cursor; |
| 347 |
|
| 348 |
for (;;) { |
| 349 |
db_c_get $c, my $key, my $data, BDB::NEXT; |
| 350 |
warn "<$!,$key,$data>"; |
| 351 |
last if $!; |
| 352 |
} |
| 353 |
|
| 354 |
db_c_close $c; |
| 355 |
|
| 356 |
DB_SEQUENCE/sequence methods |
| 357 |
Methods available on DB_SEQUENCE/$seq handles: |
| 358 |
|
| 359 |
DESTROY (DB_SEQUENCE_ornull *seq) |
| 360 |
CODE: |
| 361 |
if (seq) |
| 362 |
seq->close (seq, 0); |
| 363 |
|
| 364 |
$int = $seq->initial_value (db_seq_t value) |
| 365 |
$int = $seq->set_cachesize (U32 size) |
| 366 |
$int = $seq->set_flags (U32 flags) |
| 367 |
flags: SEQ_DEC SEQ_INC SEQ_WRAP |
| 368 |
$int = $seq->set_range (db_seq_t min, db_seq_t max) |
| 369 |
|
| 370 |
Example: |
| 371 |
my $seq = $db->sequence; |
| 372 |
|
| 373 |
db_sequence_open $seq, undef, "seq", BDB::CREATE; |
| 374 |
db_sequence_get $seq, undef, 1, my $value; |
| 375 |
|
| 376 |
SUPPORT FUNCTIONS |
| 377 |
EVENT PROCESSING AND EVENT LOOP INTEGRATION |
| 378 |
$msg = BDB::strerror [$errno] |
| 379 |
Returns the string corresponding to the given errno value. If no |
| 380 |
argument is given, use $!. |
| 381 |
|
| 382 |
Note that the BDB module also patches the $! variable directly, so |
| 383 |
you should be able to get a bdb error string by simply stringifying |
| 384 |
$!. |
| 385 |
|
| 386 |
$fileno = BDB::poll_fileno |
| 387 |
Return the *request result pipe file descriptor*. This filehandle |
| 388 |
must be polled for reading by some mechanism outside this module |
| 389 |
(e.g. Event or select, see below or the SYNOPSIS). If the pipe |
| 390 |
becomes readable you have to call "poll_cb" to check the results. |
| 391 |
|
| 392 |
See "poll_cb" for an example. |
| 393 |
|
| 394 |
BDB::poll_cb |
| 395 |
Process some outstanding events on the result pipe. You have to call |
| 396 |
this regularly. Returns the number of events processed. Returns |
| 397 |
immediately when no events are outstanding. The amount of events |
| 398 |
processed depends on the settings of "BDB::max_poll_req" and |
| 399 |
"BDB::max_poll_time". |
| 400 |
|
| 401 |
If not all requests were processed for whatever reason, the |
| 402 |
filehandle will still be ready when "poll_cb" returns. |
| 403 |
|
| 404 |
Example: Install an Event watcher that automatically calls |
| 405 |
BDB::poll_cb with high priority: |
| 406 |
|
| 407 |
Event->io (fd => BDB::poll_fileno, |
| 408 |
poll => 'r', async => 1, |
| 409 |
cb => \&BDB::poll_cb); |
| 410 |
|
| 411 |
BDB::max_poll_reqs $nreqs |
| 412 |
BDB::max_poll_time $seconds |
| 413 |
These set the maximum number of requests (default 0, meaning |
| 414 |
infinity) that are being processed by "BDB::poll_cb" in one call, |
| 415 |
respectively the maximum amount of time (default 0, meaning |
| 416 |
infinity) spent in "BDB::poll_cb" to process requests (more |
| 417 |
correctly the mininum amount of time "poll_cb" is allowed to use). |
| 418 |
|
| 419 |
Setting "max_poll_time" to a non-zero value creates an overhead of |
| 420 |
one syscall per request processed, which is not normally a problem |
| 421 |
unless your callbacks are really really fast or your OS is really |
| 422 |
really slow (I am not mentioning Solaris here). Using |
| 423 |
"max_poll_reqs" incurs no overhead. |
| 424 |
|
| 425 |
Setting these is useful if you want to ensure some level of |
| 426 |
interactiveness when perl is not fast enough to process all requests |
| 427 |
in time. |
| 428 |
|
| 429 |
For interactive programs, values such as 0.01 to 0.1 should be fine. |
| 430 |
|
| 431 |
Example: Install an EV watcher that automatically calls BDB::poll_cb |
| 432 |
with low priority, to ensure that other parts of the program get the |
| 433 |
CPU sometimes even under high load. |
| 434 |
|
| 435 |
# try not to spend much more than 0.1s in poll_cb |
| 436 |
BDB::max_poll_time 0.1; |
| 437 |
|
| 438 |
my $bdb_poll = EV::io BDB::poll_fileno, EV::READ, \&BDB::poll_cb); |
| 439 |
|
| 440 |
BDB::poll_wait |
| 441 |
If there are any outstanding requests and none of them in the result |
| 442 |
phase, wait till the result filehandle becomes ready for reading |
| 443 |
(simply does a "select" on the filehandle. This is useful if you |
| 444 |
want to synchronously wait for some requests to finish). |
| 445 |
|
| 446 |
See "nreqs" for an example. |
| 447 |
|
| 448 |
BDB::poll |
| 449 |
Waits until some requests have been handled. |
| 450 |
|
| 451 |
Returns the number of requests processed, but is otherwise strictly |
| 452 |
equivalent to: |
| 453 |
|
| 454 |
BDB::poll_wait, BDB::poll_cb |
| 455 |
|
| 456 |
BDB::flush |
| 457 |
Wait till all outstanding BDB requests have been handled. |
| 458 |
|
| 459 |
Strictly equivalent to: |
| 460 |
|
| 461 |
BDB::poll_wait, BDB::poll_cb |
| 462 |
while BDB::nreqs; |
| 463 |
|
| 464 |
CONTROLLING THE NUMBER OF THREADS |
| 465 |
BDB::min_parallel $nthreads |
| 466 |
Set the minimum number of BDB threads to $nthreads. The current |
| 467 |
default is 8, which means eight asynchronous operations can execute |
| 468 |
concurrently at any one time (the number of outstanding requests, |
| 469 |
however, is unlimited). |
| 470 |
|
| 471 |
BDB starts threads only on demand, when an BDB request is queued and |
| 472 |
no free thread exists. Please note that queueing up a hundred |
| 473 |
requests can create demand for a hundred threads, even if it turns |
| 474 |
out that everything is in the cache and could have been processed |
| 475 |
faster by a single thread. |
| 476 |
|
| 477 |
It is recommended to keep the number of threads relatively low, as |
| 478 |
some Linux kernel versions will scale negatively with the number of |
| 479 |
threads (higher parallelity => MUCH higher latency). With current |
| 480 |
Linux 2.6 versions, 4-32 threads should be fine. |
| 481 |
|
| 482 |
Under most circumstances you don't need to call this function, as |
| 483 |
the module selects a default that is suitable for low to moderate |
| 484 |
load. |
| 485 |
|
| 486 |
BDB::max_parallel $nthreads |
| 487 |
Sets the maximum number of BDB threads to $nthreads. If more than |
| 488 |
the specified number of threads are currently running, this function |
| 489 |
kills them. This function blocks until the limit is reached. |
| 490 |
|
| 491 |
While $nthreads are zero, aio requests get queued but not executed |
| 492 |
until the number of threads has been increased again. |
| 493 |
|
| 494 |
This module automatically runs "max_parallel 0" at program end, to |
| 495 |
ensure that all threads are killed and that there are no outstanding |
| 496 |
requests. |
| 497 |
|
| 498 |
Under normal circumstances you don't need to call this function. |
| 499 |
|
| 500 |
BDB::max_idle $nthreads |
| 501 |
Limit the number of threads (default: 4) that are allowed to idle |
| 502 |
(i.e., threads that did not get a request to process within 10 |
| 503 |
seconds). That means if a thread becomes idle while $nthreads other |
| 504 |
threads are also idle, it will free its resources and exit. |
| 505 |
|
| 506 |
This is useful when you allow a large number of threads (e.g. 100 or |
| 507 |
1000) to allow for extremely high load situations, but want to free |
| 508 |
resources under normal circumstances (1000 threads can easily |
| 509 |
consume 30MB of RAM). |
| 510 |
|
| 511 |
The default is probably ok in most situations, especially if thread |
| 512 |
creation is fast. If thread creation is very slow on your system you |
| 513 |
might want to use larger values. |
| 514 |
|
| 515 |
$oldmaxreqs = BDB::max_outstanding $maxreqs |
| 516 |
This is a very bad function to use in interactive programs because |
| 517 |
it blocks, and a bad way to reduce concurrency because it is |
| 518 |
inexact: Better use an "aio_group" together with a feed callback. |
| 519 |
|
| 520 |
Sets the maximum number of outstanding requests to $nreqs. If you to |
| 521 |
queue up more than this number of requests, the next call to the |
| 522 |
"poll_cb" (and "poll_some" and other functions calling "poll_cb") |
| 523 |
function will block until the limit is no longer exceeded. |
| 524 |
|
| 525 |
The default value is very large, so there is no practical limit on |
| 526 |
the number of outstanding requests. |
| 527 |
|
| 528 |
You can still queue as many requests as you want. Therefore, |
| 529 |
"max_oustsanding" is mainly useful in simple scripts (with low |
| 530 |
values) or as a stop gap to shield against fatal memory overflow |
| 531 |
(with large values). |
| 532 |
|
| 533 |
BDB::set_sync_prepare $cb |
| 534 |
Sets a callback that is called whenever a request is created without |
| 535 |
an explicit callback. It has to return two code references. The |
| 536 |
first is used as the request callback, and the second is called to |
| 537 |
wait until the first callback has been called. The default |
| 538 |
implementation works like this: |
| 539 |
|
| 540 |
sub { |
| 541 |
my $status; |
| 542 |
( |
| 543 |
sub { $status = $! }, |
| 544 |
sub { BDB::poll while !defined $status; $! = $status }, |
| 545 |
) |
| 546 |
} |
| 547 |
|
| 548 |
STATISTICAL INFORMATION |
| 549 |
BDB::nreqs |
| 550 |
Returns the number of requests currently in the ready, execute or |
| 551 |
pending states (i.e. for which their callback has not been invoked |
| 552 |
yet). |
| 553 |
|
| 554 |
Example: wait till there are no outstanding requests anymore: |
| 555 |
|
| 556 |
BDB::poll_wait, BDB::poll_cb |
| 557 |
while BDB::nreqs; |
| 558 |
|
| 559 |
BDB::nready |
| 560 |
Returns the number of requests currently in the ready state (not yet |
| 561 |
executed). |
| 562 |
|
| 563 |
BDB::npending |
| 564 |
Returns the number of requests currently in the pending state |
| 565 |
(executed, but not yet processed by poll_cb). |
| 566 |
|
| 567 |
FORK BEHAVIOUR |
| 568 |
This module should do "the right thing" when the process using it forks: |
| 569 |
|
| 570 |
Before the fork, BDB enters a quiescent state where no requests can be |
| 571 |
added in other threads and no results will be processed. After the fork |
| 572 |
the parent simply leaves the quiescent state and continues |
| 573 |
request/result processing, while the child frees the request/result |
| 574 |
queue (so that the requests started before the fork will only be handled |
| 575 |
in the parent). Threads will be started on demand until the limit set in |
| 576 |
the parent process has been reached again. |
| 577 |
|
| 578 |
In short: the parent will, after a short pause, continue as if fork had |
| 579 |
not been called, while the child will act as if BDB has not been used |
| 580 |
yet. |
| 581 |
|
| 582 |
Win32 note: there is no fork on win32, and perls emulation of it is too |
| 583 |
broken to be supported, so do not use BDB in a windows pseudo-fork, |
| 584 |
better yet, switch to a more capable platform. |
| 585 |
|
| 586 |
MEMORY USAGE |
| 587 |
Per-request usage: |
| 588 |
|
| 589 |
Each aio request uses - depending on your architecture - around 100-200 |
| 590 |
bytes of memory. In addition, stat requests need a stat buffer (possibly |
| 591 |
a few hundred bytes), readdir requires a result buffer and so on. Perl |
| 592 |
scalars and other data passed into aio requests will also be locked and |
| 593 |
will consume memory till the request has entered the done state. |
| 594 |
|
| 595 |
This is not awfully much, so queuing lots of requests is not usually a |
| 596 |
problem. |
| 597 |
|
| 598 |
Per-thread usage: |
| 599 |
|
| 600 |
In the execution phase, some aio requests require more memory for |
| 601 |
temporary buffers, and each thread requires a stack and other data |
| 602 |
structures (usually around 16k-128k, depending on the OS). |
| 603 |
|
| 604 |
KNOWN BUGS |
| 605 |
Known bugs will be fixed in the next release, except: |
| 606 |
|
| 607 |
If you use a transaction in any request, and the request returns |
| 608 |
with an operating system error or DB_LOCK_NOTGRANTED, the internal |
| 609 |
TXN_DEADLOCK flag will be set on the transaction. See C<db_txn_finish>, |
| 610 |
above. |
| 611 |
|
| 612 |
SEE ALSO |
| 613 |
Coro::BDB, IO::AIO. |
| 614 |
|
| 615 |
AUTHOR |
| 616 |
Marc Lehmann <schmorp@schmorp.de> |
| 617 |
http://home.schmorp.de/ |
| 618 |
|
