On 04May2019 1353, Nick Coghlan wrote:
On Sat, 4 May 2019 at 06:54, Neil Schemenauer <nas-python@arctrix.com> wrote:
Regarding B vs C, is the only reason to prefer C due to performance? If so, I think it is not worth the pain of it. Based on my small amount of knowledge, TLS can be really cheap. I found this article that has some benchmarks:
https://david-grs.github.io/tls_performance_overhead_cost_linux/Again, TLS is a platform specific mechanism so maybe it is worse on Windows, for example. However, it seems to me that there should be some way to do it with relatively small overhead.
Passing context everywhere doesn't come for free either. You are probably using up another register (or pushing something on the stack, depending on the ABI). If you don't need the context often and you don't switch threads often, option B is likely faster.
In embedding situations the programming model using parameters will be significantly simpler than using TLS, particularly when embedding Python into an existing app that already has a thread model. Assuming you can trivially stash the context pointer in your existing non-Python thread state, it is very easy to handle callbacks into Python. Without this, you end up storing the Python thread state itself and trying to carefully switch it back in by mutating state *outside* of your own managed state, and you run into consistency issues very quickly (I was working on doing this the week before PyCon).
It's a bit like the difference between threading.local and contextvars, and how the former carries across async call stacks while the latter are far more like "call-stack locals".
But...
I've discussed this with Eric Snow a bit here at PyCon, and I take the view that trying to migrate away from relying on TLS at this late date isn't going to be worth the hassle.
I agree, but just want to point out (for when people ask in the future) that we agreed to stick with TLS for compatibility reasons and not because it's inherently better :)
Cheers, Steve