GnuPG 2.3 Beta

[Werner Koch]

On Wed, 24 Feb 2021 12:06, Marco Ricci said:

> I see. This makes me really sad... even though I can see the temptation
> to solve the performance issue this way.

The overhead is really minimal.  For example I tried descriptor
forwarding instead of using inline data in the IPC.  This did not make
much of a difference and thus the code is not anymore used.

> I grepped the current git HEAD -- I have no idea which commit the beta
> is supposed to be, I couldn't find a tag or anything -- and saw that you

  gpgconf --show-versions | head -1

shows the commit.

> don't use SQLite's WAL mode [1], which is designed for better
> reader/writer-concurrency than naive full file locking. Have you tried
> that already? From what the documentation says, SQLite's native Unix

We use Sqlite for Tofu for quite some time and did some experiments.
Given that gpg is short-living process you don't get any advantage from
that.  Really, a dedicted server process is the most robust and fastest
solution.

> (Or is the design already at the WONTFIX stage?)

We need this and it was a long standing plan to unify the database
storage.  And we expected complains about yet another process ;-)

> configure/configure.ac. But in T4510 you started shipping (requiring?)
> SQLite 3.28. Perhaps you need to update and/or re-evaluate which SQLite

Yeah, we should eventually update our copy. We have a copy of sqlite on
our server due to our build process.

> version you require at a minimum? This might then be a good time to
> check if requiring a newer SQLite and then using WAL mode solves your

Long running daemons can cache, shor tunning processes can't.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210224/8708b9e2/attachment-0001.sig>