You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Call DuplicateHandle with the handle and the target process and it'll give you a handle that you can pass to that process. Handles are pointers to opaque types.
Take care when sending a handle over a pipe to a process with a different architecture, as one side may write 4 bytes while the other reads 8 bytes. Might be better to just always read/write 8 bytes.
The text was updated successfully, but these errors were encountered:
Hello @retep998, thank you for the suggestion, as well as the tips and traps to avoid :)
From my point of view, another big challenge of this is that as the mechanism behind the fd-passing is very different, There is the matter of how to abstract this (if at all possible) into a clean common API.
ie:
Unix only requires a unix socket (path actually, that fd-passing server-side opens by itself) + FileDescriptor
Windows requires a handle to the target Process (still no idea how it's retrieved), + FileHandle
While it's probably easy to not care for the real data behind the FileHandle/FileDescriptor, I wonder how challenging it will be to abstract the unix socket (path) versus Process Handle.
Well you still need some way to send it to the target process, so a pipe (aka a unix socket) is still one way to do it (just with a completely different API to use them than on unix). To get the target process handle, you'd either get it from libstd when you create the child via the AsRawHandle impl, or you'd get the process ID, which is a system wide identifier, probably via GetProcessId, and then pass it to the other process and OpenProcess the id.
Call
DuplicateHandle
with the handle and the target process and it'll give you a handle that you can pass to that process. Handles are pointers to opaque types.Take care when sending a handle over a pipe to a process with a different architecture, as one side may write 4 bytes while the other reads 8 bytes. Might be better to just always read/write 8 bytes.
The text was updated successfully, but these errors were encountered: