hai shi added the comment:
This bpo isn't a bug, so I close it now. If there are some enhancements need to
be discussed, we can reopen it:)
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
hai shi added the comment:
> 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.
Sorry, I don't explain it good enough. You have said what I wanted to say:)
> Yes, but if the extension is
Madhu added the comment:
* hai shi
<1629695372.88.0.481350414879.issue44...@roundup.psfhosted.org>
Wrote on Mon, 23 Aug 2021 05:09:32 +
> hai shi added the comment:
>> which can be wrapped within the calls to PyGILState_Ensure/Release.
> OK, it's a good idea. But I think this
hai shi 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.
> python is initialized within that entrypoint
python is initialized when you run python :)
--
Madhu added the comment:
* hai shi
<1629603770.32.0.682495978946.issue44...@roundup.psfhosted.org>
Wrote on Sun, 22 Aug 2021 03:42:50 +
> hai shi added the comment:
> How about this one?
>
> if (!Py_IsInitialized()) {
> return -1;
> }
[When this extension is loaded into a C
hai shi added the comment:
How about this one?
int foo(void)
{
printf(stderr, "foo BEGIN\n");
if (!Py_IsInitialized()) {
fprintf(stderr, "python already initialized\n");
return -1;
}
const char *module_name = "foo";
PyGILState_STATE state = PyGILState_Ensure();
PyObject
New submission from Madhu :
Attached zip file has a test case which illustrate the problem:
A python process (`dload.py') loads up a shared library (`libfoo1.so')
and makes a call to a foreign function `foo'. `foo' Initializes Python
and creates makes a call to PyModule_New at which point
