Цель в предотвращении ошибки ERROR_NOT_ENOUGH_MEMORY в Windows, которая
совсем не информативна для пользователя и возникает в этом случае (когда
файл открыт read-only и короче запрошенного размера).
Это вынужденный читинг для "починки" сравнительных бенчмарков при
размещении БД в /dev/shm.
Проблема в том, что актуальные ядра Linux для файлов размещенных в tmpfs
возвращают mincore=false. В результате, в простейших бенчмарках видно
двукратное снижение производительности, просто из-за вызовов write()
выполняемых для prefault.
Из-за этого, в таких синтетических тестах, новая libmdbx становится
существенно медленнее предыдущих версий, в том числе LMDB.
Это решает проблему срабатывания проверочного утверждения при сборке для
платформ где тип off_t шире соответствующих полей структуры flock,
используемой для блокировки файлов.
Ранее, при конвертации очень коротких интервалов в формат фиксированной
точки 16-точка-16, всегда выполнялось замещение нуля единицей. Т.е. если
интервал был не нулевым, но меньше 15.259 микросекунд (1/65536 секунды),
то вместо 0 возвращалось 1.
Это приводило к тому, что сумма длительности отдельных стадий нередко
была больше чем общее время фиксации транзакции. Проблема усугублялась,
если получаемые значения аккумулировались по серии транзакций.
Теперь такая защита от нуля выполняется только для общего времени,
но не для отдельных стадий.
Было:
latency(ms): preparation=72.69 gc=72.69 write=73.04 sync=141.40 ending=72.69 whole=142.14
Аккумулированная сумма длительности этапов ВТРОЕ(!) больше общей длительности.
Стало:
latency(ms): preparation=0.00 gc=0.02 write=0.79 sync=67.98 ending=0.00 whole=140.81
Аккумулированная сумма длительности этапов меньше общей длительности,
так как для каждой транзакции общая длительность возвращается не менее 15.259 микросекунд.
Here are some changes to avoid recursive acquisition of SRW-lock,
which is still in use:
- Read transactions don't acquire the shared SRW-lock with `MDBX_NOTLS.
- Memory-mapping of DB is always kept while DB opened,
therefore following limitations are:
- DB file can't be shrinked while it used,
including auto-shrink due to auto-compactification with corresponding geometry settings.
- The upper limit of DB size can't be changed while DB is used.
- The DB can grow within the upper size limit defined while opening by a first process,
but this does not work under Wine since there is no `NtExtendSection()` function.
Partially fix https://github.com/erthink/libmdbx/issues/203
