From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#14803: Setting close-on-exec flag consistently Date: Sat, 06 Jul 2013 20:54:53 +0300 Message-ID: <834nc7y3o2.fsf@gnu.org> References: <51D7DFAF.3030500@cs.ucla.edu> <83obafylf1.fsf@gnu.org> <51D8514F.8090307@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1373133373 19925 80.91.229.3 (6 Jul 2013 17:56:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jul 2013 17:56:13 +0000 (UTC) Cc: 14803@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 06 19:56:13 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UvWiQ-0005fB-Fv for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Jul 2013 19:56:10 +0200 Original-Received: from localhost ([::1]:37660 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvWiQ-0000z4-3V for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Jul 2013 13:56:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvWiM-0000yz-3A for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2013 13:56:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UvWiL-00053x-4U for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2013 13:56:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvWiL-00053q-1H for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2013 13:56:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UvWiJ-0005nq-JG for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2013 13:56:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jul 2013 17:56:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14803 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 14803-submit@debbugs.gnu.org id=B14803.137313330922199 (code B ref 14803); Sat, 06 Jul 2013 17:56:03 +0000 Original-Received: (at 14803) by debbugs.gnu.org; 6 Jul 2013 17:55:09 +0000 Original-Received: from localhost ([127.0.0.1]:35158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UvWhQ-0005lr-1v for submit@debbugs.gnu.org; Sat, 06 Jul 2013 13:55:08 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:49701) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UvWhK-0005l2-Lh for 14803@debbugs.gnu.org; Sat, 06 Jul 2013 13:55:04 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MPJ00B000C82I00@a-mtaout21.012.net.il> for 14803@debbugs.gnu.org; Sat, 06 Jul 2013 20:54:56 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MPJ00BY10FI2230@a-mtaout21.012.net.il>; Sat, 06 Jul 2013 20:54:55 +0300 (IDT) In-reply-to: <51D8514F.8090307@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76010 Archived-At: > Date: Sat, 06 Jul 2013 10:18:07 -0700 > From: Paul Eggert > CC: 14803@debbugs.gnu.org > > On 07/06/2013 04:31 AM, Eli Zaretskii wrote: > > 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. > > The gnulib replacements do that sort of thing too. Emacs > uses a hybrid approach, which uses gnulib for some things > and its own (pre-gnulib) solution for others, and it should > be possible to keep the hybrid working in this case. In the > long run it may be better to merge the two approaches rather > than maintain a hybrid I don't know how easy that would be, since the infrastructure used in Emacs for this is very elaborate, and might contradict with general-purpose use of gnulib. > but that issue doesn't need to be addressed now. Right. > > 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. > > That's the intent of this patch. On systems like w32 that > lack SOCK_CLOEXEC, the code creates sockets just as it did > before (using plain 'socket' and 'accept' rather than > 'socket' and 'accept4' with SOCK_CLOEXEC). Given that w32 redirects calls to 'socket' to 'sys_socket', which is implemented on w32.c, will the above still work? > The only difference is that the proposed code then invokes fcntl > (fd, F_SETFD, FD_CLOEXEC) to set the close-on-exec flag; this is > needed on POSIXish systems that don't have SOCK_CLOEXEC. From what > you say, on w32 platforms it's OK if this is a no-op. w32.c's fcntl > currently returns SOCKET_ERROR for this fcntl call, which should be > fine, since Emacs doesn't check for an error. > > > 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. > > This should be OK, since the w32 port doesn't define > HAVE_MKOSTEMP, so Emacs should use mkstemp or mktemp as it > did before. Emacs will now invoke fcntl (fd, F_SETFD, > FD_CLOEXEC) on the resulting file descriptor but that should > be OK as described above. > > > 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). > > The proposed patch does this, as fcntl.h should #define > O_CLOEXEC to O_NOINHERIT on w32. > > > So I think we should simply not compile lib/fcntl.c and lib/pipe2.c > > (including their dependency modules) on MS-Windows. > > That should be OK. w32.c will need minor tweaks to support > F_DUPFD_CLOEXEC and pipe2, something along the following lines. I'm OK with the rest of your proposals. I assume that lib/fcntl.c and lib/pipe2.c will not be compiled for w32, due to some configure test? Or did you have something else in mind? Thanks.