On Wed, 18 Mar 2020 13:35:16 +0000
Anders Munch <a...@flonidan.dk> wrote:
> Chris Angelico [mailto:ros...@gmail.com]:
> > And by that logic, globals are even more capable. I don't understand your
> > point. Isn't the purpose of the tstate parameters to avoid the problem of
> > being unable to have multiple tstates within the same OS thread? I think
> > I've
> > missed something here.
>
> The point is that because threads can't preempt themselves, this:
>
> /*1*/
> {
> Py_something(other_tstate);
> }
>
> and this:
>
> /*2*/
> {
> PyInterpreterState* old_tstate = tstate;
> tstate = other_state;
> Py_something();
> tstate = old_tstate;
> }
>
> is effectively equivalent, provided tstate is thread-local. Both will work
> equally well from the hypothetical C callback that wants to use a different
> subinterpreter.
This example is mixing up the notion of interpreter state and thread
state.
Here is a more realistic example:
struct UserData {
PyInterpreterState* interp;
};
// Callback given to a third-party C library
void my_c_callback(void* opaque) {
struct UserData* user_data = (struct UserData*) opaque;
PyGILState_STATE gstate;
gstate = PyInterpreter_GILStateEnsure(user_data->interp);
// ...
PyInterpreter_GILStateEnsure(user_data->interp, gstate);
}
Of course this implies the existence of a PyInterpreter_GILState API
that currently doesn't exist. In this model, the "thread-local" thread
state is a *per-interpreter* thread-local. A *process-wide*
thread-local thread state cannot work if we want -- in some distant
future -- to be able to run several subinterpreters concurrently.
In any case, the amount of disagreement and/or misunderstanding in this
discussion is a strong hint that it needs a PEP to hash things out and
explain them clearly, IMHO.
Regards
Antoine.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/EKZJYO75QBDKZA4A2RR43PKDYEJRD7HC/
Code of Conduct: http://python.org/psf/codeofconduct/
