Comments (5)
I think this was discussed, and the conclusion was something like: Even though it's hard to expose a safe API on top of shmem to avoid races, letting the user write to a shared memory buffer with an unsafe API could be desirable, but it's just not done.
It should be a straight-forward addition I think, a patch would probably be welcomed :)
cc @antrik, did I get that right?
from ipc-channel.
I'm quite new to Rust, but I might try to write a patch when I get more confidence. Thanks
from ipc-channel.
We need to clarify the use case here.
What IpcSharedMemory
currently allows, is creating a shared memory object initialised with some pre-existing data, and sending that to other processes, where it is mapped, so the data can be read there. This is not zero-copy, since creation of the object allocates new memory that is initialised by copying some existing data.
This could be fixed by extending the API to allow decoupling the allocation of the buffer from initialisation. This way we could create a new buffer for each frame, then fill it with data, and finally send it to the consumer process, where it is read and finally freed.
One possible approach for that would be introducing some kind of proto-SHM-object, which is allocated but not initialised, and can be borrowed mutably to fill it with data, before it's converted into a regular immutable SHM object for sending. Another approach would be allowing some kind of callback for supplying the initialisation data -- this would be less flexible in how the data can be supplied (probably precluding DMA?), but keep the API entirely safe, by not exposing uninitialised memory to users.
An entirely different case would arise if we want permanent shared memory, that can be overwritten by the producer process with new data repeatedly even after sending it off to a consumer process. This would be much more involved, since it requires some kind of inter-process locking to make it safe. Wrapping this in some kind of safe abstraction might be somewhat tricky I suspect, though I haven't spent too much thought on it. (And I'm not really familiar with inter-process locking mechanisms.)
from ipc-channel.
from ipc-channel.
Let's not over-engineer this. The more flexible variant is not necessarily better, if it requires an unsafe interface. Do you actually need this flexibility for your use case? Please be more specific about what you are trying to do.
Same regarding buffer reuse. Of course we could synchronise the use of mutable buffers using only IPC channel messages, rather than adding some other cross-process synchronisation mechanism -- but that's likely less efficient. At any rate, if we try to reuse buffers, we definitely need some kind of cross-process synchronisation, which is always fairly expensive -- so it has to be very carefully considered, to make sure it's actually an optimisation... Again, we need specifics.
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.