Hallvard, thank for your comments.
2014-12-02 14:20 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>:
On 10/23/2014 07:13 AM, leo(a)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
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.