Dynamically allocation messages and remapping them in the destination's address space is slow. We could speed up rpc performance by utilizing shared memory.
I'm thinking: opening a channel between two processes, and send messages back and forth via recyclable shared buffers.
(This would be different to a future streaming interface where we could fire-and-forget messages in a circular buffer. Instead this would still wait for a response.)
One idea is that when you have a channel between two processes, you could grab a buffer from a channel, and it would be a pool of shared memories. The request would be written to the beginning, the message would be sent to the receiver, which would write the response to the same shares buffer, and then send a ping back.
I also thought about using separate sending and receiving buffers but I'm leaning against it because the original sender would have to signal back to the receiver that it was done with the response buffer.
Technically, we could do this without channels. Each pair of {sender, receiver} could have a set of shared buffers, which would be more efficient memory wise, but there wouldn't be a way to "close" the channel between two processes. Perhaps we could have a "clean up" method to deallocate all buffers between two processes.
Dynamically allocation messages and remapping them in the destination's address space is slow. We could speed up rpc performance by utilizing shared memory.
I'm thinking: opening a channel between two processes, and send messages back and forth via recyclable shared buffers.
(This would be different to a future streaming interface where we could fire-and-forget messages in a circular buffer. Instead this would still wait for a response.)
One idea is that when you have a channel between two processes, you could grab a buffer from a channel, and it would be a pool of shared memories. The request would be written to the beginning, the message would be sent to the receiver, which would write the response to the same shares buffer, and then send a ping back.
I also thought about using separate sending and receiving buffers but I'm leaning against it because the original sender would have to signal back to the receiver that it was done with the response buffer.
Technically, we could do this without channels. Each pair of {sender, receiver} could have a set of shared buffers, which would be more efficient memory wise, but there wouldn't be a way to "close" the channel between two processes. Perhaps we could have a "clean up" method to deallocate all buffers between two processes.