================
@@ -274,10 +274,8 @@ static Status spawn_process(const char *progname, const
FileSpec &prog,
self_args.AppendArgument(llvm::StringRef("platform"));
self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
-#ifndef _WIN32
launch_info.AppendDuplicateFileAction((int)shared_socket.GetSendableFD(),
(int)shared_socket.GetSendableFD());
----------------
labath wrote:
I don't understand what's the problem with that. I'm pretty sure that zero is
not a valid handle value
(https://devblogs.microsoft.com/oldnewthing/20040302-00/?p=40443), so it can't
conflict with STDIN_FILENO.
Relatedly, I had an idea which might alleviate some of your concerns. While I
firmly believe that getting right of the `child_process_inherit` constructor
argument is the right thing to do, I'm not entirely happy that this results in
making *all* pipe handles inheritable. In the description I propose creating a
helper function which creates a copy of the handle which can be inherited. On
windows this would call `DuplicateHandle` with `bInheritHandle=TRUE` and on
posix it would be a no-op (as we're able to change the CLOEXEC flag on the fd
later).
If we had that, we could also easily ensure that the returned handle does not
conflict with our "reserved" values -- if `DuplicateHandle` returns 0/1/2, just
call it again until it returns something bigger. It's kinda gross, but I also
somehow like it :P
https://github.com/llvm/llvm-project/pull/137978
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
