On 5/13/22 2:29 PM, Adam D Ruppe wrote:
On Friday, 13 May 2022 at 18:23:58 UTC, H. S. Teoh wrote:
On Thu, May 12, 2022 at 11:45:47PM +0000, Guillaume Piolat via
It's a problem because it goes from solving "no accidental race
condition" and you get "people forget to add shared or __gshared and
their shared library silently fail" situation. You could have none of
that with explicit TLS.
Valid point.
Yeah, I used to be pro-TLS by default, then got bit by it several times
and moved to the fence, and now I'm anti.
Data races aren't actually prevented by it (maybe forcing you to specify
shared or tls would at least get you think about it though) and lots of
things mysteriously fail if you forget about it.
I disagree. I'd rather have a program fail in a way that is predictable
and explainable than one with memory corruption or race conditions. In
fact, I'd rather have 100 TLS confusion failures than one memory
corruption failure.
Either way you will have failures due to under-specification. Which
failures do you choose to debug?
Note that with the no shared access update, this will be more obvious of
a mistake.
This a case where I think forcing explitness would be better than either
default
Perhaps this would be reasonable. But I find the default reasonable too.
But we also have this confusing dynamic:
|scope |no attribute| shared |static |
|--------|------------|--------|-----------|
|module |TLS |global |TLS (no-op)|
|function|local |local! |TLS |
|class |instance |global |TLS |
Honestly, if we changed `static` storage class to `@tls`, and then
required it whenever you wanted TLS data, it would be a huge improvement.
-Steve
