Mailing List Archive

(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@cryptobitch.de> wrote:

Hi,&#13;
&#13;
I want to use the GPGME Python bindings in a concurrent way.&#13;
&#13;
In the documentation of the Python bindings at&#13;
http://files.au.adversary.org/crypto/gpgme-python-howto.html I find no&#13;
mention of multithreading.&#13;
&#13;
In the GPGME documentation at&#13;
https://www.gnupg.org/documentation/manuals/gpgme/Multi_002dThreading.html#Multi_002dThreading&#13;
I find the note, that I need to call "gpgme_check_version" before doing&#13;
any multithreaded operations.&#13;
&#13;
Then again I find only this section about version checking in the&#13;
Python binding's documentation:&#13;
http://files.au.adversary.org/crypto/gpgme-python-howto.html#gpgme-version-check&#13;
In this section the version check is done via a subprocess call to&#13;
"gpgme-config --version".&#13;
&#13;
Is the call to "gpgme_check_version" maybe done implicitly by the&#13;
Python bindings?&#13;
&#13;
Do I have to call "gpgme-config --version" before to safely do&#13;
multithreaded operations with the Python bindings?&#13;
&#13;
Thank you for any insights,&#13;
Jan&#13;
&#13;
_______________________________________________&#13;
Gnupg-users mailing list&#13;
Gnupg-users@gnupg.org&#13;
https://lists.gnupg.org/mailman/listinfo/gnupg-users&#13;
&#13;

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@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@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@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@gnupg.org
> > https://lists.gnupg.org/mailman/listinfo/gnupg-users
> >
>


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mon, 16 Jan 2023 07:55, Jan Girlich said:
> Is the call to "gpgme_check_version" maybe done implicitly by the
> Python bindings?

Yes. See gpgme/lang/python/src/core.py

# check_version also makes sure that several subsystems are properly
# initialized, and it must be run at least once before invoking any
# other function. We do it here so that the user does not have to do
# it unless she really wants to check for a certain version.
check_version()

> Do I have to call "gpgme-config --version" before to safely do

No, this is a helper to compile against gpgme - it returns suggested
compiler and linker flags.

Make sure that one context object is only used by one thread at a time.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein