-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Closed
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleA new feature, making something new possibleS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!
Description
This is a sub-issue of #17667. See that issue for more high-level details.
What problem does this solve or what need does it fill?
We are using !Send resources to store mostly global data, such as handles, winit windows, etc. This blocks the resources-as-components effort, which seeks to eliminate the usage of resources.
What solution would you like?
In order to unblock resources-as-components, we need to remove any !Send components and replace them with the use of thread_local!. The benefit of using thread_local! in this context is that the !Send resources we are working with are (at least sometimes) !Sync. Wrapping a var in thread_local! ensures safety without requiring the wrapped type to be Sync or Send.
What alternative(s) have you considered?
We have talked about:
- Using
staticvars withoutthread_local!, but that requires the var beSync. - Creating
!SendWorlds to store this data. This is the long term plan (see parent issue), but right now we just need a short-term solution so resources-as-components is unblocked
Metadata
Metadata
Assignees
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleA new feature, making something new possibleS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!