Interprocess communication
highmountaintea opened this issue · comments
Hi, is there any plan to support faster communications between two deno processes, or between parent and child deno processes? I am wondering if ProtoBuf might provide a mechanism that's faster than typical HTTP or IPC communications. This would be a boon for dispatch based architecture.
As I google others articles, seem Deno is using other framework Flatbuffer (also made by google), to dual with V8 and Rust communicating, instead of using Protobuf.
However, similar question that I want to ask: is there any IPC / FlatBuffer channel that open for other program to communicate with Deno?
We removed flatbuffer from Deno, and that was only for privileged communication between the JavaScript runtime and Rust.
Depends on what you really mean by "child process". Deno supports web workers, and the communication to them is in the standard way. Deno.dial() and Deno.listen() could be used for TCP communication.
Communicating via Windows or Linux raw sockets might be an interesting enhancement.
For example, we have a node.js project where we want a central web server dispatch the messages to its child processes, instead of using clustering. But this type of architecture has a lot of overhead over clustering in node.js.
Since deno has invested much effort in message passing, I am wondering whether that can benefit the messaging performance between parent/child processes.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I need to use unix sockets to communicate with a c++ daemon process in out project. Are we getting this in Deno?
@rahul-dutt-sharma Deno can already connect to unix sockets in --unstable.
const conn5 = await Deno.connect({ path: "/foo/bar.sock", transport: "unix" });
This was closed for staleness but count me in for interested. Though Deno has Workers, I've found the hard way that they aren't a real solution to processes - Workers can get "stuck" in permanent ways like through bad npm dependencies that break the module graph, and the memory consumed by Workers doesn't get cleaned up, so at the end of the day, we've got to use processes, and it'd be great if there was a nice way to communicate with them.