Madhu <enom...@meer.net> added the comment:
* hai shi <rep...@bugs.python.org> <1629695372.88.0.481350414879.issue44...@roundup.psfhosted.org> Wrote on Mon, 23 Aug 2021 05:09:32 +0000 > hai shi <shihai1...@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.] ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44913> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
