Multithreading with GPGME Python Bindings

[Jan Girlich]

Hi Robert,

On Mon, 2023-01-16 at 11:53 -0500, Robert J. Hansen wrote:
> I don't have an immediate answer for you I'd suggest starting by
> learning how Python's multi-threading support is more smoke and
> mirrors than reality. That may lead you to an answer to your
> question.

you seem to be quite new to the topic of Python and multi-threading, so
let me give you the relevant basics relating to my question.

Yes, the GIL is making cPython thread-safe and thus blocking threads.
But only when processing Python bytecode. When an external operation
runs, like gnupg encrypting something or I/O operations, the GIL is
released and another thread can run. So multi-threading computationally
intensive gnupg operations can have performance improvements.

Also, the GIL is no issue with multi-processing, which is the
constructive answer I prefer to "GIL is a problem", instead of "smoke
and mirrors".

I can recommend https://superfastpython.com/multiprocessing-pool-gil/
on this topic.

Thank you,
Jan

> 
> On Jan 16, 2023 1:55 AM, Jan Girlich <vollkorn at cryptobitch.de> wrote:
> > Hi,
> > 
> > I want to use the GPGME Python bindings in a concurrent way.
> > 
> > In the documentation of the Python bindings at
> > http://files.au.adversary.org/crypto/gpgme-python-howto.html I find
> > no
> > mention of multithreading.
> > 
> > In the GPGME documentation at
> > https://www.gnupg.org/documentation/manuals/gpgme/Multi_002dThreading.html#Multi_002dThreading
> > I find the note, that I need to call "gpgme_check_version" before
> > doing
> > any multithreaded operations.
> > 
> > Then again I find only this section about version checking in the
> > Python binding's documentation:
> > http://files.au.adversary.org/crypto/gpgme-python-howto.html#gpgme-version-check
> > In this section the version check is done via a subprocess call to
> > "gpgme-config --version".
> > 
> > Is the call to "gpgme_check_version" maybe done implicitly by the
> > Python bindings?
> > 
> > Do I have to call "gpgme-config --version" before to safely do
> > multithreaded operations with the Python bindings?
> > 
> > Thank you for any insights,
> > Jan
> > 
> > _______________________________________________
> > Gnupg-users mailing list
> > Gnupg-users at gnupg.org
> > https://lists.gnupg.org/mailman/listinfo/gnupg-users
> > 
> 
> (Please forgive the HTML email, sending from my phone)
> 
> Given Python is effectively single-threaded through the global
> interpreter lock, this may turn out to be a total non-issue. Although
> I don't have an immediate answer for you I'd suggest starting by
> learning how Python's multi-threading support is more smoke and
> mirrors than reality. That may lead you to an answer to your
> question.
> 
> On Jan 16, 2023 1:55 AM, Jan Girlich <vollkorn at cryptobitch.de> wrote:
> > Hi,
> > 
> > I want to use the GPGME Python bindings in a concurrent way.
> > 
> > In the documentation of the Python bindings at
> > http://files.au.adversary.org/crypto/gpgme-python-howto.html I find
> > no
> > mention of multithreading.
> > 
> > In the GPGME documentation at
> > https://www.gnupg.org/documentation/manuals/gpgme/Multi_002dThreading.html#Multi_002dThreading
> > I find the note, that I need to call "gpgme_check_version" before
> > doing
> > any multithreaded operations.
> > 
> > Then again I find only this section about version checking in the
> > Python binding's documentation:
> > http://files.au.adversary.org/crypto/gpgme-python-howto.html#gpgme-version-check
> > In this section the version check is done via a subprocess call to
> > "gpgme-config --version".
> > 
> > Is the call to "gpgme_check_version" maybe done implicitly by the
> > Python bindings?
> > 
> > Do I have to call "gpgme-config --version" before to safely do
> > multithreaded operations with the Python bindings?
> > 
> > Thank you for any insights,
> > Jan
> > 
> > _______________________________________________
> > Gnupg-users mailing list
> > Gnupg-users at gnupg.org
> > https://lists.gnupg.org/mailman/listinfo/gnupg-users
> > 
>