-
Notifications
You must be signed in to change notification settings - Fork 130
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
Comments
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'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:
The text was updated successfully, but these errors were encountered: