JavaScriptKit and Swift Concurrency

Related Projects Swift for WebAssembly
1

i’ve spent a few days investigating the state of WebAPIKit and JavaScriptKit, and i find that the library is exceedingly Concurrency-unfriendly. many fundamental types such as JSString are non-Sendable (they have some lazy initialization magic inside of them) and this effectively excludes them from being used as static let properties.

is there any background to why JavaScriptKit and JSString are implemented like this, or is it simply because the library predates Swift Concurrency?

2

JavaScript and WebAssembly are single-threaded, no? The only way you can do multithreading is by spinning off a worker, and that worker won't share any variables with the UI code or other workers, so there's no shared global state to have data races.

3

You’re right, the current implementation of JSString isn’t great. The lazy initialization isn’t strictly necessary, and we’re planning to revise it.

That said, JS object references themselves are inherently not Sendable, because JavaScript objects can’t be shared across Web Workers. So even if we made JSString not to use lazy var, it wouldn’t make sense to conform Sendable.
This is actually intentional in the design of JavaScriptKit, especially because the Wasm SDK supports multithreaded environments. You can see some examples here.

If your environment is guaranteed to be single-threaded, I’d recommend adding @unchecked Sendable yourself.

2 Likes
4

thanks for the details, the reason i ask is because in WebAPIKit, there are a lot of static let string constants such as Strings.Object, which are lazily initialized once and shared across all threads, and as one would expect, raise a number of Swift Concurrency errors when trying to update that library to the Swift 6 language standard.

an alternative is to allocate and construct fresh instances of these JSStrings on every member access, but that seems comically inefficient. what is the best road forward here?

5

We are using TLS for the same issue inside JavaScriptKit.

As another direction (even though it's not an option for you right now), we are working on a new declarative FFI solution that will reduce the need to cache JSString inside Swift memory space. Declarative JS interop · Issue #290 · swiftwasm/JavaScriptKit · GitHub

6

If it helps, I've been dealing with the same issue in node-swift: native modules are usually loaded from the main thread, but Node.js also has workers. I've come up with a few different options for solving the issue with ergonomics around Sendability:

  1. (Current approach) mark all JS types with the global @NodeActor, which has a custom executor that hops to the main Node.js thread. This has great ergonomics… as long as you're okay accepting that your module won't function inside workers.
  2. Make all JS types actors, with an executor that targets the context (worker/main thread) on which they were created. This is good for correctness, but makes it impossible to declare synchronous methods/APIs. Methods can still be synchronous at runtime if there's no context switching, but it would be very easy to e.g. accidentally call into a nonisolated async method and introduce a hop.
  3. Make all JS types @unchecked Sendable classes, and have all of their methods take a isolation: isolated NodeContext = #isolation parameter. This is a middle-ground in terms of correctness, because it guarantees (at compile time) that you are calling the API on some Node.js thread, but not that it's the same one on which the object was created. Though this could get very verbose and is probably less relevant for Wasm where there are no "non-JS threads" to worry about in the first place.

With SwiftPM features traits, I wonder if the right approach (for both JavaScriptKit and node-swift) might be to implement a "Workers" trait that discloses the more complex API surface, otherwise making everything MainActor/NodeActor.

Very interested in seeing if any of these approaches work for JavaScriptKit, or if there are any other options worth exploring.

7

Thank you for your input! Unfortunately, Option 1 is not our option since the thread feature is mandatory for some users. We are currently recommending users to employ Option 2 like this example.

In our case, we have _runtime(_multithreaded), so it might be worth adding Sendable conformance conditionally to provide better ergonomics for most of users.

1 Like
8

ah yes, i think this is the right approach for the WebAPIKit bindings.

i looked at the source code for those types, and i have a few observations (in no particular order)

  • ThreadLocal seems to manually box non-object values into classes, but iirc, the Swift runtime can already do this at the language level (through the as AnyObject boxing pattern), so i’m unsure what purpose ThreadLocal.Box serves.
  • LazyThreadLocal is also a class, but i am not sure why, it could be a struct. it would also need to be made public or otherwise duplicated for use in WebAPIKit or a fork of that library.
  • JSString is a class-in-a-struct type, which means it would get wrapped in two layers of indirection (three with LazyThreadLocal), i wonder if something like this would be more efficient:
import _CJavaScriptKit

extension JS
{
    public
    final class StringConstant
    {
        @usableFromInline
        let reference:JavaScriptObjectRef

        @inlinable
        init(reference:JavaScriptObjectRef)
        {
            self.reference = reference
        }

        @inlinable
        deinit
        {
            swjs_release(self.reference)
        }
    }
}
extension JS.StringConstant
{
    @inlinable public convenience
    init(encoding string:consuming String)
    {
        let reference:JavaScriptObjectRef = string.withUTF8
        {
            swjs_decode_string($0.baseAddress!, Int32.init($0.count))
        }
        self.init(reference: reference)
    }
}

of course i’m new to the codebase so this could all be completely uninformed, but i’m interested in hearing your thoughts :)

1 Like