Threading in gjs

Is there any chance gjs could support threading? Presumably SpiderMonkey has good support for WebWorkers and SharedArrayBuffer, but perhaps gjs relies on other components that aren’t thread-safe, or it would be too easy to break the thread safety by using certain introspected libraries?

I guess gjs is considered mainly as a simple scripting tool, but with Typescript and something like ts-for-gjs it can be so much more. I think GTK needs bindings for more mainstream strictly typed high-level languages to survive, and Typescript is surprisingly good. There are also GI bindings for node, but I think there are some incompatibilities in the API, and it could end up marginalising gjs, which would be a shame, because I suspect gjs has a lighter footprint, and it’s easy to dive straight into on any Linux distro (and even Mac) without all the baggage of npm.

There are no threading primitives in JavaScript, but you can very much use threading in GJS. You’ll just have to implement your threaded functionality in an introspectable library, much like the GNOME platform libraries do already.

The easiest way to do that is using GTask, which can ensure that memory being managed by the JavaScript engine is not freed off-thread and that any memory allocated there is bound to a variable in the main thread.

SpiderMonkey itself doesn’t support Web Workers. They’re part of HTML, not JavaScript.

I don’t think it’s out of the question that GJS might gain some API like Worker, at some point in the future. But JavaScript itself is not multi-threaded so like Andy said, threading and synchronization as it is done in other programming languages is probably never going to happen.

But presumably I can’t run Javascript on the extra threads?

I suppose browsers set up a separate Javascript context for each thread then. But there’s also API for passing messages between threads, and atomic operations on shared memory, and I thought gjs might be able to use SpiderMonkey’s implementation, along with whatever it uses to launch workers.

That’s correct. Essentially it can only be executed in the same thread that it is managing memory in, and vice-versa.

Yes, that might happen some day. (But it’s Gecko that launches the workers and does the postMessage thing… if I’m not mistaken, that just doesn’t exist in SpiderMonkey.)

Nice, I was just looking for discussions on that topic for GitHub - sonnyp/OhMySVG: Reduce the size of SVGs

I use this JavaScript library, SVGO, which is quite CPU intense on complex SVGs so my use case is “run expansive JavaScript without blocking the UI”.

I agree Web Worker API would be kinda neat and a nice addition to https://gitlab.gnome.org/GNOME/gjs/-/issues/265 but you can achieve something similar by spawing a new GJS process and doing custom IPC. I might write this as a Worker polyfill, let me know if you are interested.

See Subprocesses in GJS | Andy Holmes

If you need anything more than that, you’re probably better off using a different language anyway with bindings as @andyholmes pointed out.