This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author enometh
Recipients enometh, shihai1991
Date 2021-08-23.11:45:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20210823.171447.1197282322255614747.enometh@meer.net>
In-reply-to <1629695372.88.0.481350414879.issue44913@roundup.psfhosted.org>
Content
*  hai shi <report@bugs.python.org> <481350414879.issue44913@roundup.psfhosted.org">1629695372.88.0.481350414879.issue44913@roundup.psfhosted.org>
Wrote on Mon, 23 Aug 2021 05:09:32 +0000

> hai shi <shihai1991@126.com> added the comment:
>> which can be wrapped within the calls to PyGILState_Ensure/Release.
> OK, it's a good idea. But I think this enhancement will break the back
> compatibility.

I don't understand.

Wherever I make a Py C call from the extension (libfoo1.so), I have to
wrap it up within calls to PyGILState_Ensure/Release to avoid
segfaults right?

That's how I understood your comment.

So this is on the user to avoid the segfaults, right?

And you saying my extension will not be backward compatible, i.e. it
will not work on older versions of python? (pam-python still supports
py27, I think)

Or are you saying something can be done in Python's components to
handle this use case transparently? so the user won't have to put GIL
locks in his code

(They aren't required in the normal extension case AFAICT)

>> python is initialized within that entrypoint
> python is initialized when you run python :)
[Yes, but if the extension is loaded into a C program (i.e. not from
python then the extension (libfoo1.so) has to call Py_Initialize at
that point.]
History
Date User Action Args
2021-08-23 11:45:04enomethsetrecipients: + enometh, shihai1991
2021-08-23 11:45:04enomethlinkissue44913 messages
2021-08-23 11:45:04enomethcreate