Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending an IpcReceiver over a previously sent IpcChannel doesn't work on Windows #310

Open
zaddach opened this issue Mar 7, 2023 · 4 comments

Comments

@zaddach
Copy link

zaddach commented Mar 7, 2023

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).

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();
@wusyong
Copy link
Member

wusyong commented Jul 7, 2024

I hit the similar problem when attempting to add multiprocess support for Servo on Windows. It resulted in the same panic in oob_data.

@wusyong
Copy link
Member

wusyong commented Sep 6, 2024

I wonder if we can replace the implementation with anonymous pipes instead. It states it's safe to duplicate the handle to other process.

@zaddach
Copy link
Author

zaddach commented Oct 1, 2024 via email

@wusyong
Copy link
Member

wusyong commented Oct 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants