interface proximity. That API is published by Oracle at "http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/C/frame_main.html":http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/C/frame_main.html.
The defines generator is imperfect and includes some defines that are not
flags. While it could be improved, it is easier to delete the incorrect ones.
Thus, if you decide to rebuild the defines, you will need to edit the resulting
file. This may be necessary if using a different release of DB4 than the ones
the authors developed against. In nearly every case the defines generator works
flawlessly.
The authors have put all possible caution into ensuring that DB and Ruby cooperate.
The memory access was one aspect carefully considered. Since Ruby copies
when doing String#new, all key/data retrieval from DB is done with a 0 flag,
meaning that DB will be responsible. See "this":http://groups.google.com/group/comp.databases.berkeley-db/browse_frm/thread/4f70a9999b64ce6a/c06b94692e3cbc41?tvc=1&q=dbt+malloc#c06b94692e3cbc41
news group posting about the effect of that.
The only other design consideration of consequence was associate. The prior
version used a Ruby thread local variable and kept track of the current
database in use. The authors decided to take a simpler approach since Ruby is green
threads. A global array stores the VALUE of the Proc for a given association
by the file descriptor number of the underlying database. This is looked
up when the first layer callback is made. It would have been better considered
if DB allowed the passing of a (void *) user data into the alloc that would
be supplied during callback. So far this design has not produced any problems.