4 ms·

> 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 (

by qudat 4mo ago

> 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/ 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?

jankiel 4mo ago
this is what I wonder as well.
whilenot-dev 4mo ago
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#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#inter-process-communication-ipc https://chromiumembedded.github.io/cef/general_usage.html#in...
billywhizz 4mo ago
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/lib.rs https://github.com/denoland/deno/blob/main/cli/rt_desktop/li... - https://github.com/littledivy/laufey/blob/main/webview/src/main_linux.cc https://github.com/littledivy/laufey/blob/main/webview/src/m...
- billywhizz 4mo ago
  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.

by qudat 4mo ago

jankiel 4mo ago

this is what I wonder as well.

whilenot-dev 4mo ago

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#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#inter-process-communication-ipc https://chromiumembedded.github.io/cef/general_usage.html#in...

billywhizz 4mo ago

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/lib.rs https://github.com/denoland/deno/blob/main/cli/rt_desktop/li... - https://github.com/littledivy/laufey/blob/main/webview/src/main_linux.cc https://github.com/littledivy/laufey/blob/main/webview/src/m...

billywhizz 4mo ago
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.