Mark Shannon wrote:
The point I'm making is that adding `tstate` parameters everywhere is unnecessary. Using a thread local variable is much less intrusive and is at least as capable.
Objectively speaking, what would be the specific difference(s) in behavior and performance between using a thread-local variable vs passing a tstate parameter? A more in-depth "pros vs cons" analysis of each approach might help to make the argument points more clear, as it seems some of the parties involved in the discussion are talking past each other to some degree, or at least aren't completely on the same page. It might also help to find a specific C-API function to benchmark, to show how substantial the supposed performance differences could be. Intuitively, it seems like passing around an extra parameter would add some penalty, but it's not clear to me as to how much that would *realistically* add in performance cost compared to accessing the threadstate through a thread-local variable. It seems like it depends on exactly how often `_ThreadState_GET()` would have to be called, but that's not at all obvious considering the scope of the changes.
Using a thread local variable is much less intrusive and is at least as capable.
I'm not sure that I'm clear on how the tstate parameter would be additionally intrusive, considering that the changes only affect the internal parts of the C-API. I would agree if it were to be arbitrarily added to public API since it would break backwards compatibility, but that doesn't seem to be the case here. From the perspective of being intrusive, it seems like it's adding some code churn and a potential merge conflict to resolve locally. That seems like an inconvenience to us rather than something that would be intrusive to users. Also, regarding the thread-local variable example demonstrated w/ godbolt (thanks for providing those :-) ), it seems like it would be very clear to access the *current* threadstate that was created by the *main* interpreter, but how would you go about resolving the following?: 1) A different threadstate from another interpreter and OS thread 2) A different threadstate created from the same OS thread, but from a different interpreter (as Antoine mentioned earlier) From my understanding, those scenarios seem to be a significant concern in the context of subinterpreters. If we could also see example(s) which address those scenarios with a thread-local variable instead of a tstate parameter, I think it would allow for more objective comparison between them. Regards, Kyle Stanley On Wed, Mar 18, 2020 at 6:36 AM Mark Shannon <mark@hotpy.org> wrote:
On 17/03/2020 7:00 pm, Steve Dower wrote:
On 17Mar2020 1803, Chris Angelico wrote:
On Wed, Mar 18, 2020 at 3:50 AM Mark Shannon <mark@hotpy.org> wrote:
The accessibility of a thread-local variable is a strict superset of that of a function-local variable.
Therefore storing the thread state in a thread-local variable is at least as capable as passing thread-state as a parameter.
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.
You haven't. Separating the Python thread from the "physical" thread is indeed the point.
That seems like a strawman argument; maybe I'm misunderstanding Steve. It seems to me that Steve is implying that using thread-local variables somehow prevents that separation. It does not.
The point I'm making is that adding `tstate` parameters everywhere is unnecessary. Using a thread local variable is much less intrusive and is at least as capable.
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/CLRCMGUC... Code of Conduct: http://python.org/psf/codeofconduct/