[Lldb-commits] [PATCH] Apply SOCK_CLOEXEC flag to socket API functions in order to avoid handle leakage to a forked child process.

[Zachary Turner]

Can I also request that the variable *not* be called close_on_exec?.  It is
possible to implement an equivalent on Windows, but calling it close on
exec will be confusing to people on Windows.  Can we come up with a more
generic name?  On Windows this would be called "inherit handles", which to
me sounds like a better name than close on exec, but I may be biased.  Is
"inherit handles" confusing to people on non-Windows?

In other words, I'm proposing

virtual lldb::ConnectionStatus ConnectionFileDescriptor::Connect(const char
*s, Error *error_ptr, bool close_on_exec = true);

would become

virtual lldb::ConnectionStatus ConnectionFileDescriptor::Connect(const char
*s, Error *error_ptr, bool inherit_handles = false);



On Mon Nov 10 2014 at 4:45:46 PM Greg Clayton <clayborg at gmail.com> wrote:

> I don't think this is a good default. Sockets are often used for IPC after
> fork/exec, but I would like to make a way to specify close on exec by
> supplying a boolean argument to ConnectionFileDescriptor() when creating
> it. Then clients will opt into this by force as they will need to supply
> the argument. Or you can make a default argument that defaults to true for
> "close_on_exec".
>
> So maybe a boolean to:
>
>     virtual lldb::ConnectionStatus ConnectionFileDescriptor::Connect(const
> char *s, Error *error_ptr, bool close_on_exec = true);
>
> Then this gets passed along to whomever creates the IOObject subclass and
> they each do the right thing if they can
>
> http://reviews.llvm.org/D6204
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20141111/2651af6c/attachment.html>