Comments (4)
Well, for one, ipc-channel
actually already offers a mechanism (though quite limited in scope) for dealing with shared memory, which clients are supposed to use explicitly where it makes sense. (When transferring large amounts of data, mostly.) It might be useful to use it automatically (and transparently) for large transfers, to avoid the complexity and overhead of packet splitting -- see #98 for some ideas.
As for using shared memory for IPC in general, that's quite a different story: it's one of these things that actually start looking much less attractive when you consider the details :-) Specifically -- aside perhaps from narrow use cases that can work with lockless data structures -- doing IPC over shared memory still requires issuing system calls, to do synchronisation. For small messages at least, the system calls totally dominate performance -- so if we need to do system calls anyway, we can just as well transfer the actual data directly with them, which is likely to offer better performance. (Since the IPC paths are generally well optimised at the OS level.)
Even for medium-sized messages, using the system mechanisms is probably cheaper. Shared memory might seem attractive, because in theory, you could avoid copying the actual data. That however would require setting up shared memory buffers for every message we want to transfer -- adding extra overhead, which will usually outweigh the saved copy. (Copying memory is in fact a relatively cheap operation, which is pretty hard to beat.) Plus it would make the API more tricky to use. See #126 for some relevant discussion.
Having said all that, I did actually recently ponder the possibility of using a shared memory based mechanism, to improve portability and consistency: the basic mechanism could be the same on all platforms; and porting would boil down to plugging in system-specific primitives for managing shared memory regions and for inter-process locking/synchronisation...
from ipc-channel.
Another important issue is that ipc-channel
also needs the ability to send IPC channel endpoints over IPC channels, not just plain data. This seems rather tricky and expensive with a mechanism based on shared memory alone. (I'm not even sure it's possible at all?)
Note that this happens a lot when using a communication style based on remote procedure calls, where every request message carries a distinct channel for the reply. It might be argued that this is not the optimal approach I guess -- but doing otherwise would entail radically different usage patterns...
from ipc-channel.
FYI, memfd was designed as a safe shared-memory mechanism for Linux. It can be used to share raw data with another process thanks to a file descriptor (which is needed to send IPC channels endpoints over IPC channel). Moreover, memfd support memory sealing which is needed when dealing with untrusted peer (as explained in the man page).
from ipc-channel.
Also see #125.
from ipc-channel.
Related Issues (20)
- macos::OsIpcSharedMemory::from_bytes aborts if passed an empty slice
- Implement `std::error::Error` on error types
- IpcBytesSender::send will hang up when receiver is not work. HOT 1
- Panic on large data transfer HOT 1
- IpcReceiver hang, forking leaks file descriptors, problem/discussion HOT 1
- Release a new version HOT 2
- panic when some conditions
- Could you please publish a new version to crates.io?
- cargo-careful panics due to `stat` being left uninitialized
- Channel between 64-bit and 32-bit process
- Trivial Example Not Working HOT 6
- Why can I only connect to IpcSender and not IpcReceiver? HOT 8
- IpcOneShotServer::accept is blocking and has no non-blocking version HOT 2
- Vulnerability in crossbeam-utils dependency HOT 1
- Apple recommends against direct use of Mach
- Sending an IpcReceiver over a previously sent IpcChannel doesn't work on Windows HOT 1
- macOS builds are broken with recent rustc HOT 2
- Doc page not being updated HOT 1
- Panic post upgrading from rustc 1.66 to later versions on MacOS
- Ability to set custom name for the server
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ipc-channel.