Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904

[leo@yuriev.ru]

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.