bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14803: Setting close-on-exec flag consistently


From: Eli Zaretskii
Subject: bug#14803: Setting close-on-exec flag consistently
Date: Sat, 06 Jul 2013 14:31:30 +0300

> Date: Sat, 06 Jul 2013 02:13:19 -0700
> From: Paul Eggert <address@hidden>
> 
> Tags: patch
> 
> Here's a patch I'd like to install into Emacs soon.
> It changes Emacs so that it creates file descriptors
> that are close-on-exec unless they are intended to
> be propagated to child processes.
> This patch may affect the Microsoft Windows ports
> so I'm sending it to bug-gnu-emacs first.
> Much of the new code is imported from gnulib.

Sorry, this won't fly.  The Windows build has its own implementations
of 'pipe' and 'socket' (because it needs to make them behave like
Posix APIs, and also because it needs to watch each subprocess and
each socket for the benefit of 'select', 'waitpid', SIGCHLD, etc.).
So the replacements from gnulib won't do.

Looking at the Emacs sources, I see that the Windows implementation of
'pipe' already makes it non-inheritable (see sys_pipe), so this
problem does not exist in the Windows build.

Socket handles _are_ inherited, but making them non-inheritable is not
easy (some say impossible in the general case), and since no one
complained till now, I'm willing to live with that until we hear some
real problems.

For mktemp/mkstemp in filelock.c, sys_open in w32.c already makes all
handles not inheritable by default, so that problem doesn't exist,
either.

As for emacs_open, it needs to use O_NOINHERIT instead of O_CLOEXEC
(or just use zero, since w32.c already adds the O_NOINHERIT flag in
sys_open).

So I think we should simply not compile lib/fcntl.c and lib/pipe2.c
(including their dependency modules) on MS-Windows.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]