New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std.socket: replace static this with crt_constructor #8670
base: master
Are you sure you want to change the base?
Conversation
Thanks for your pull request, @WalterBright! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + phobos#8670" |
8302141
to
b280a9e
Compare
What's the purpose here ? |
Seriously? No. |
As in core.cpuid, the reason is having a static this means that a ModuleInfo will need to be generated for every object file that imports it. Since the static constructor has no dependencies on any other module, by initializing it with the C library constructor will not produce such dependencies. |
It's just good engineering to eliminate unnecessary dependencies. |
ModuleInfo also gets in the way of using betterC, which does not support ModuleInfo. |
None of these are actually eliminating dependencies. Rather making it harder for people to use them without C. |
It eliminates the dependency on ModuleInfo and the dependency on druntime.
All pragma(crt_constructor) actually does is put a pointer to the function in a named section. Besides, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't do this:
- It will possibly be using uninitialized GC, which can be catastrophic
- It uses exceptions, which depends on runtime initialization anyway
As in core.cpuid, the reason is having a static this means that a ModuleInfo will need to be generated for every object file that imports it. Since the static constructor has no dependencies on any other module, by initializing it with the C library constructor will not produce such dependencies.
This is a clear reason to fix the ModuleInfo ABI. I remember @deadalnix telling me how broken ModuleInfo is on DMD at DConf. Why don't we implement order independent construction and add a priority tag to it? People already need to do shenanigans to make independent construction working and it possibly doesn't work on separate compilation module, due to how ModuleInfo is designed.
It's also an annoying real issue I have at production code with huge inter-module dependencies. Every time I include a module with a static this
that also includes itself indirectly gets broken at runtime, on runtime initialization, and this is the biggest flaw of ModuleInfo.
We can surely implement something that doesn't need the requirement above mentioned by you, just like what C does. Also, ABI breakage isn't a reason to not change this, because the ABI is already broken.
And so does
It also still relies on the existence of a D runtime, what with its use of Anyway, this is not the way to do it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #5470 for an example of eliminating static this.
Another approach to this: |
108 lines of changes, abandoned as too much work Also by Andrei, also a lot of work. Yeah, one could do lazy initialization, though one would lose the advantages of immutable variables.
Yes, but
Yes, but does not require
The constructor does indeed throw, good catch. This can be fixed, as the error is fatal anyway.
I wish people would include bugzilla references when making statements like this.
Ironically, that's a reason for this PR. |
Both modules have to have a
which is deliberate. With these cycles, how is the compiler to know which one gets run first? (At least D detects the error, with C one will arbitrarily get run first. If that isn't the right order, too bad.) The solution is the user will have to specify which one comes first. The way to do that is to create a third module with just the static constructor in it that needs to run first, and have both modules import that module. That eliminates the dependency loop. I don't know of any other way to do it that would be robust. |
BTW, this |
Not both modules imported directly, but if they indirectly import one that has a
The creation of another module is the shenanigans I was talking about. And due to how ModuleInfo is designed, it potentially doesn't run. That works on one compiler invocation, but what if I compile that isolated module that doesn't get imported by anyone? Well, the linker eliminates those unused symbols. |
How can the compiler determine which one should go first? Isn't it a failure of proper encapsulation for modules that each import each other? (I think some languages don't even allow that.) |
If you compile an isolated module, ~all symbols are unused. If a public section is removed, that's a compiler bug.
(Neat doesn't! (Because it can't compile it. :P)) Anyway, this is the sort of code that should prompt soul-searching about the language. I understand the motivation, but as we'd say at work: "merge it, but backlog a TODO task to refactor that design." |
This is the only
static this
left in Phobos. Removing it makes for reducing need for ModuleInfo.