Hallvard, thank for your comments. 2014-12-02 14:20 GMT+03:00 Hallvard Breien Furuseth <[email protected]>: > On 10/23/2014 07:13 AM, [email protected] wrote: >> >> Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature. >> (...) >> +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id, >> size_t txn); > > > Some thoughts about this: > > Instead of trusting the return value, it seems safer to re-check > with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe > except on Windows, where file locks from dead processes may > linger for a while until the OS reclaims them.
I agree that usign mdb_reader_pid() is a better way. > Don't call it OOMkiller just because that's how you use it. > Others might do something else, like sending a reader a signal > which it interprets as "please wake up and finish your txn". > Or it might decide this process is the one which should give up. Could you suggest something other instead of "oomkiller"? Be noted, the "dreamcatcher" feature has a critical bug, which I has found and made fix while work on ITS#7968 & ITS#7987. Currently we hard testing a new code. So, in a week I plan to update both of the patches. > This feature could make it interesting to let readers and writers > tell each other things: Reserve some unused space in the reader > table slots for stuff the reader's caller could put there, and > some space for an impatient writer to leave a note. Could go > in an independent commit if there is any demand for it though. Communications between readers and writers may be interesting, but I think it is over-engineering in the LMDB context. IMHO the LMDB's code has a lot of technical debt, so it is more usefull to re-implement all of from a scratch, under a rules of perfectly-clean codestyle. May be I will do this, but on a basis and after a release of 1Hippeus - it is a extreme performance engine for zero-copy mesaging in a shared memory, partially like Intel DPDK. Leonid.
