servo
Sending an IpcReceiver over a previously sent IpcChannel doesn't work on Windows
I'm trying to set up a secondary channel through which I can transfer Senders/Receivers/SharedMemory. Since the secondary channel has been created in a single process, both its server and client named pipe have the same PID. When the secondary channel's pipe handle gets transferred to the other process (via DuplicateHandle), the PID for its server end isn't updated. When another handle (e.g., from a shared memory blob) is now sent over the connection, the transfer will fail on the other end, as the PID encoded in the OutOfBand message is wrong (and the handle hasn't been duplicated into the receiver's process).
- The code for getting the server PID is here
- The PID check on the receiver side is here
- Windows' pipefs behavior of setting server/client PID at pipe creation time is documented here
Pseudocode of what I'm trying to do at the sender's side:
let sender: IpcSender<Requests> = IpcSender::connect(server_name).unwrap();
let (secondary_sender, secondary_sender_other_end) = channel<SecondaryRequests>().unwrap();
sender.send(Requests::Init(secondary_sender)).unwrap();
let shared_memory = IpcSharedMemory::from_byte(0xba, 1024 * 1024);
// The next command will fail on the receiver side, because the server PID of the secondary OsIpcSender is wrong (still the one of the current process, not the transferred OsIpcReceiver)
secondary_sender.send(SecondaryRequests::Mem(shared_memory)).unwrap();
I hit the similar problem when attempting to add multiprocess support for Servo on Windows. It resulted in the same panic in oob_data.
I wonder if we can replace the implementation with anonymous pipes instead. It states it's safe to duplicate the handle to other process.
Anonymous pipes aren't very popular on Windows because they don't support overlapped operations. Internally they're a pair of named pipes anyways, just that the name isn't visible outside the Windows-internal code.
On Fri, Sep 6, 2024 at 7:55 AM Ngo Iok Ui (Wu Yu Wei) @.***> wrote:
I wonder if we can replace the implementation with anonymous pipes instead. It states it's safe to duplicate the handle to other process.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
yeah I saw there are lots of overlapped operations are not supported which ipc-channel needs them. I wonder how Firefox does it because it also uses named pipe for sure.