[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[felk]

Change by felk :


--
nosy: +felk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[STINNER Victor]

STINNER Victor  added the comment:

The bpo-46295 was marked as a duplicate of this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-40522: Get the current Python interpreter state from Thread Local 
Storage (autoTSSkey).

--
versions: +Python 3.10 -Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[Erlend Egeberg Aasland]

Change by Erlend Egeberg Aasland :


--
nosy: +erlendaasland

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[h-vetinari]

Change by h-vetinari :


--
nosy: +h-vetinari

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[Gabriel Amine Eddine]

Change by Gabriel Amine Eddine :


--
nosy: +gabrielhae

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[STINNER Victor]

STINNER Victor  added the comment:

I marked bpo-10915 as a duplicate of this issue.

See also bpo-1021318: "PyThreadState_Next not thread safe".

--
components: +C API
title: [subinterpreters] Support subinterpreters in the GIL state API -> 
[subinterpreters] Make the PyGILState API compatible with subinterpreters
versions:  -Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-4202: [subinterpreters] Multiple interpreters and readline module 
hook functions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[Ronald Oussoren]

Change by Ronald Oussoren :


--
nosy: +ronaldoussoren

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[Sebastian Berg]

Sebastian Berg  added the comment:

In NumPy ufuncs and datatype casting (iteration) we have the following setup:

   user-code (releasing GIL) -> NumPy API -> 3rd-party C-function 

(in the ufunc code, numpy is the one releasing the GIL, although others, such 
as numba probably hook in and replace that.)
Now, I want the 3rd-party C-function to be able to report errors in a 
reasonable way. Which, in my opinion means it must be able to grab the GIL, set 
an error (potentially release the GIL) and return an error result.
In theory, setting the error could be deferred to some later "cleanup" when the 
GIL is held, but that just does not seem practical to me.

One thing which may make this not as problematic is that the all of this can be 
expected to run within a Python created thread, so I somewhat think the initial 
proposal here would effectively fix the current NumPy usage (I am not sure).


The reason I ask/post this is, that this is all part of public-API which 
requires a complete re-implementation very soon. While extensions to that new 
API may be possible, that is always a bit painful, so it would be good to know 
how that API should be designed right now.

At this point, it seems that I should design the 3rd-party C-function API so 
that it is passed a `void *reserved = NULL` (always NULL) to be able to pass a 
`PyThreadState *` or `PyInterpreterState *` at some point safely. (Or a 
`PyThreadState **`/ `PyInterpreterState **`?)

In the majority of cases, I could already pass this right now, but I have 
currently no clear idea of what is the best practice. I also need to take such 
an argument (requiring new API) in at least one place. If we know how this will 
pan out, adding it sooner rather than later would be good, since it will make 
future transition/adoption faster or at least easier.

As far as I understand, right now PyGILState_Ensure()` not working is probably 
the single most blocking issue for correct subinterpreter support in NumPy, 
since this is baked into public API it may take years for true support in the 
above way, but we may be able to go a large part of the way now. My problem is 
that I can only do that if I am clear on what is needed.

--
nosy: +seberg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com