Skip to content
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

Strict Concurrency Support #462

Open
migueldeicaza opened this issue May 7, 2024 · 0 comments
Open

Strict Concurrency Support #462

migueldeicaza opened this issue May 7, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@migueldeicaza
Copy link
Owner

migueldeicaza commented May 7, 2024

I have checked in in the strict-concurrency branch support for Swift 6.0 Strict Concurrency, it still has about 48 issues that need to be addressed.

Currently, the bulk of the problems are the shared public variable for singletons, as that one states that it might be a problem, so I will need a plan for what to do there - not with a blanket fix, but on a case-by-case basis because:

  • Clay mentions that "most of core/ must be thread safe", and also said that things like scenes are not.
  • There are a number of types there (like UndoRedo) that might have a thread safe API, but would do things that are inherently not thread safe.
  • Clay mentions that APIs that deal with the scene are not thread safe, that matches what I would expect of a UI toolkit due to their complexity

Plan

The original plan was to assume that everything was @mainactor bound, but I now think this is a bad idea. For example, it is possible to instantiate safely entire Node trees from a PackedScene in the background, but only attaching must take place on the main thread.

So perhaps we need to take a different approach here:

In other cases, it's as you say, even classes that are not thread-safe in principle can be safely used from an arbitrary thread as long as they don't interact with non-thread-safe objects being dealt with from other threads. The most promiment example would be Nodes; you can take a PackedScene resource and instantiate it so you have a tree of Nodes and you can do it on any thread. However, adding that to the scene tree must be done on the main thread or with some kind of sync mechanism.

I think that we can start by assuming that everything is @mainactor bound, unless we have a reason to expose the API to non-main actor users (ClassDB for example might be suitable for multi-threaded use, it lives in core, and sort of makes sense, but we need to validate this assumption).

The @mainactor for the class also has some cascading effects to a few other places, like generated thunk methods.

List of types in Core that have surfaced APIs to SwiftGodot

AESContext AStar2D AStar3D AStarGrid2D ClassDB ConfigFile Crypto CryptoKey DTLSServer DirAccess EncodedObjectAsID Engine EngineDebugger EngineProfiler Expression FileAccess GDExtension GDExtensionManager Geometry2D Geometry3D HMACContext HTTPClient HashingContext IP Image ImageFormatLoader ImageFormatLoaderExtension Input InputEvent InputEventAction InputEventFromWindow InputEventGesture InputEventJoypadButton InputEventJoypadMotion InputEventKey InputEventMIDI InputEventMagnifyGesture InputEventMouse InputEventMouseButton InputEventMouseMotion InputEventPanGesture InputEventScreenDrag InputEventScreenTouch InputEventShortcut InputEventWithModifiers InputMap JSON MainLoop Marshalls MissingResource Mutex OS Object OptimizedTranslation PCKPacker PackedDataContainer PackedDataContainerRef PacketPeer PacketPeerDTLS PacketPeerExtension PacketPeerStream PacketPeerUDP ProjectSettings RandomNumberGenerator RefCounted Resource ResourceFormatLoader ResourceFormatSaver ResourceImporter ResourceLoader ResourceSaver ResourceUID Script ScriptExtension ScriptLanguage ScriptLanguageExtension Semaphore Shortcut StreamPeer StreamPeerBuffer StreamPeerExtension StreamPeerGZIP StreamPeerTCP StreamPeerTLS TCPServer TLSOptions Thread Time Translation TranslationPO TranslationServer UDPServer UndoRedo WeakRef WorkerThreadPool X509Certificate XMLParser
@migueldeicaza migueldeicaza changed the title Sendable Support Strict Concurrency Support May 9, 2024
@migueldeicaza migueldeicaza added the enhancement New feature or request label Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant