Add multithreadingEnabled switch to NativeConfig
#2327
Conversation
WojciechMazur
force-pushed the
WojciechMazur:feature/multithreading-switch
branch
from
e5cf020
to
adcc89a
| copy(multithreadingSupport = enabled) | ||
| .withLinktimeProperties( | ||
| linktimeProperties.updated( | ||
| "scala.scalanative.meta.linktimeinfo.isMultithreadingEnabled", | ||
| enabled | ||
| ) | ||
| ) | ||
| } |
lolgab
Jul 14, 2021
•
Contributor
I think the setting should be defined in one place instead of two.
What happens if I set:
nativeConfig ~= {_.withLinktimeProperties(
linktimeProperties.updated(
"scala.scalanative.meta.linktimeinfo.isMultithreadingEnabled",true)
)
}
?
Will this enable "half" of the multithreading code (just the runtime one without the compiler) ?
And if I do:
nativeConfig ~= {
_.withMultithreadingSupport(true)
.withLinktimeProperties(linktimeProperties - "scala.scalanative.meta.linktimeinfo.isMultithreadingEnabled")
}
It will have only the compiler support without the runtime.
I think we should define only a single setting that can be enabled/disabled atomically.
I think the setting should be defined in one place instead of two.
What happens if I set:
nativeConfig ~= {_.withLinktimeProperties(
linktimeProperties.updated(
"scala.scalanative.meta.linktimeinfo.isMultithreadingEnabled",true)
)
}?
Will this enable "half" of the multithreading code (just the runtime one without the compiler) ?
And if I do:
nativeConfig ~= {
_.withMultithreadingSupport(true)
.withLinktimeProperties(linktimeProperties - "scala.scalanative.meta.linktimeinfo.isMultithreadingEnabled")
}It will have only the compiler support without the runtime.
I think we should define only a single setting that can be enabled/disabled atomically.
WojciechMazur
Aug 10, 2021
Author
Contributor
That was a good point, I've replaced isMultithreadingEnabled and isWindows properties with predefined values (computed from NativeConfig or Platform settings) and introduced custom properties that can be set by the user. At this point Discover.linktimeProperties might be obsolete, however, I guess we can keep it for future uses, eg. reading props from env variable - right now introducing parsing would be quite problematic.
That was a good point, I've replaced isMultithreadingEnabled and isWindows properties with predefined values (computed from NativeConfig or Platform settings) and introduced custom properties that can be set by the user. At this point Discover.linktimeProperties might be obsolete, however, I guess we can keep it for future uses, eg. reading props from env variable - right now introducing parsing would be quite problematic.
…ites - introduce predefinded and custom linktime properties
This PR adds a new field in the NativeConfig, allowing us to remain current low-overhead single-threaded runtime, as well as test experimental multithreading support, as pointed in #2323
By placing this field in the NativeConfig we'd be able to pass specific flags to Clang if needed in the future, eg. to prepare GC for multithreading execution. Additionally thanks to adding a new linktime-property we would be able to perform link-time conditional branching, eg. to disable locking without any additional overhead.