Hallvard, thank for your comments.

2014-12-02 14:20 GMT+03:00 Hallvard Breien Furuseth h.b.furuseth@usit.uio.no:

On 10/23/2014 07:13 AM, leo@yuriev.ru 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.