refactor: use mmap to replace socket for ipc #88
Conversation
Signed-off-by: silver-ymz <yinmingzhuo@gmail.com>
| reader | ||
| .write(&[0u8; 1], Duration::from_secs(1)) | ||
| .expect("Failed to write."); | ||
| unsafe { reader.read::<[u8; 1]>(false) }.expect("Failed to read."); |
There was a problem hiding this comment.
I think the writing is done if no exception raised? Because the mmap-sync is sync
There was a problem hiding this comment.
I think the writing is done if no exception raised?
Yes. But the other side don't know when the writing is done.
There was a problem hiding this comment.
Is this the common pattern for stream based interface? For socket interface, receiver also don't know when the write operation is done by the writer?
There was a problem hiding this comment.
I think the reader need to spawn a spin-loop thread to actively read from mmap to a buffer, and the ChannelTrait read is designed to read from the buffer when needed.
There was a problem hiding this comment.
Is this the common pattern for stream based interface? For socket interface, receiver also don't know when the write operation is done by the writer?
For socket interface, the reader will be blocked until the write operation is done by the writer. But mmap-sync won't block anything. For read operations other than the first read, we can use spin-loop to block it mannually. But for the first time, it will directly panic.
I think the reader need to spawn a spin-loop thread to actively read from mmap to a buffer
Using the way, we will give up the advantage of zero-copy with mmap.
There was a problem hiding this comment.
For read operations other than the first read, we can use spin-loop to block it mannually.
Since the mmap is the only IPC data link, I dont think there are any method for writer to "notify" the receiver that the writting is done.
Using the way, we will give up the advantage of zero-copy with mmap.
The writer doesn't check if the sent data is consumed, so the next data will overwrite the previous one and causes "lossing packet"
There was a problem hiding this comment.
Since the mmap is the only IPC data link, I dont think there are any method for writer to "notify" the receiver that the writting is done.
We can store extra state data in an additional mmap file. Because the memory is shared between 2 processes, all sync primitives can be used, like locks, etc.
The writer doesn't check if the sent data is consumed, so the next data will overwrite the previous one and causes "lossing packet".
We can use write data in different place, also it's possible to check if the sent data is consumed. mmap-sync use RCU to implement similar function.
There was a problem hiding this comment.
Thanks for your explanation. @usamoi will implement this feature, and we're single producer, single consumer so it can be much easier.
Spin-lock is not a good solution since it consumes lots of cpu resources.
There was a problem hiding this comment.
Seems https://github.com/servo/ipc-channel can be a good baseline
WIP
Close #70
Current problem:
mmap-syncdoesn't provide a way to check if the writer has completed a write operation. Performing a read operation before starting a write can even cause a panic. Maybe we should try using self-managed mmap and condvar.