-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
static
vars withoutthread_local!
, but that requires the var beSync
. - Creating
!Send
World
s 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!