[qudat]

> Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. -- https://docs.deno.com/runtime/desktop/bindings/

I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it must be IPC? Maybe the claim "shared memory space" is more an architectural description than an OS-level claim?

[billywhizz]

from what i understand after a quick look at the source is it uses a C ABI to communicate between the WebView/CEF "host" application and the deno runtime which is loaded by the host as a shared library.

marshalling of values back and forth between the JS/C++/Rust layers still has to happen but these are just straight C api calls in process under the hood so much less overhead than having to do serdes across a socket/pipe.

- https://github.com/denoland/deno/blob/main/cli/rt_desktop/li...

- https://github.com/littledivy/laufey/blob/main/webview/src/m...

[billywhizz]

also notable that deno has a very low overhead bindings layer for doing JS->C/C++/Rust/Native interop using v8 fastapi calls where possible.

[whilenot-dev]

My guess is that it's not using IPC on OS level, like D-Bus on Linux, but rather a supervisior process starts and orchestrates child processes as needed. And all these processes use a shared memory model.

Here's the CEF docs on processes: https://chromiumembedded.github.io/cef/general_usage.html#pr...

EDIT: ...and the CEF docs on IPC: https://chromiumembedded.github.io/cef/general_usage.html#in...

[jankiel]

this is what I wonder as well.