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.
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 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.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.