BDB

 view release on metacpan or  search on metacpan

BDB.pm  view on Meta::CPAN

82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
 
While request submission and execution is fully asynchronous, result
processing is not and relies on the perl interpreter calling C<poll_cb>
(or another function with the same effect).
 
=item result
 
The request results are processed synchronously by C<poll_cb>.
 
The C<poll_cb> function will process all outstanding aio requests by
calling their callbacks, freeing memory associated with them and managing
any groups they are contained in.
 
=item done
 
Request has reached the end of its lifetime and holds no resources anymore
(except possibly for the Perl object, but its connection to the actual
aio request is severed and calling its methods will either do nothing or
result in a runtime error).
 
=back

BDB.pm  view on Meta::CPAN

510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
=item BDB::max_poll_time $seconds
 
These set the maximum number of requests (default C<0>, meaning infinity)
that are being processed by C<BDB::poll_cb> in one call, respectively
the maximum amount of time (default C<0>, meaning infinity) spent in
C<BDB::poll_cb> to process requests (more correctly the mininum amount
of time C<poll_cb> is allowed to use).
 
Setting C<max_poll_time> to a non-zero value creates an overhead of one
syscall per request processed, which is not normally a problem unless your
callbacks are really really fast or your OS is really really slow (I am
not mentioning Solaris here). Using C<max_poll_reqs> incurs no overhead.
 
Setting these is useful if you want to ensure some level of
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 EV watcher that automatically calls
BDB::poll_cb with low priority, to ensure that other parts of the

Changes  view on Meta::CPAN

87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
          can't get destroyed while requests are still outstanding.
        - fixed a few minor stack issues.
 
1.71 Tue Jul 29 05:30:24 CEST 2008
        - add const char * to typemap for possible 5.6 support.
        - untested support for db4.3.
        - berkelydb needs seriously larger stacksizes (on x86 at least)
          then what the default xthread.h provides.
 
1.7  Thu Jul 17 14:09:25 CEST 2008
        - use a totally different mechanism to pass callbacks to
          requests (see manpage).
        - optional arguments before the callback can now be left out.
        - use less memory per request, probably be a bit faster, too.
        - fix a memory leak (callbacks were never freed).
        - add a basic testsuite.
        - add (untested) support for cdsgroup_begin and db_exists.
        - make BDB::VERSION compatible to UNIVERSAL::VERSION.
 
1.6  Tue Jul  8 10:34:58 CEST 2008
        - add new BDB::VERSION function for easy version checks.
        - work around broken bsd headers once more.
        - support for berkeley db 4.7 added.
        - add support for log_set_config and it's constants,
          and set_intermediate_dir_mode.

README  view on Meta::CPAN

72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
        The request has been executed and is waiting for result processing.
 
        While request submission and execution is fully asynchronous, result
        processing is not and relies on the perl interpreter calling
        "poll_cb" (or another function with the same effect).
 
    result
        The request results are processed synchronously by "poll_cb".
 
        The "poll_cb" function will process all outstanding aio requests by
        calling their callbacks, freeing memory associated with them and
        managing any groups they are contained in.
 
    done
        Request has reached the end of its lifetime and holds no resources
        anymore (except possibly for the Perl object, but its connection to
        the actual aio request is severed and calling its methods will
        either do nothing or result in a runtime error).
 
BERKELEYDB FUNCTIONS
    All of these are functions. The create functions simply return a new

README  view on Meta::CPAN

436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
BDB::max_poll_reqs $nreqs
BDB::max_poll_time $seconds
    These set the maximum number of requests (default 0, meaning
    infinity) that are being processed by "BDB::poll_cb" in one call,
    respectively the maximum amount of time (default 0, meaning
    infinity) spent in "BDB::poll_cb" to process requests (more
    correctly the mininum amount of time "poll_cb" is allowed to use).
 
    Setting "max_poll_time" to a non-zero value creates an overhead of
    one syscall per request processed, which is not normally a problem
    unless your callbacks are really really fast or your OS is really
    really slow (I am not mentioning Solaris here). Using
    "max_poll_reqs" incurs no overhead.
 
    Setting these is useful if you want to ensure some level of
    interactiveness when perl is not fast enough to process all requests
    in time.
 
    For interactive programs, values such as 0.01 to 0.1 should be fine.
 
    Example: Install an EV watcher that automatically calls BDB::poll_cb