BDB
view release on metacpan or search on metacpan
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
=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
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.
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
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
( run in 0.739 second using v1.01-cache-2.11-cpan-9b1e4054eb1 )