X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Tue, 21 Jul 2009 18:23:20 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: close on exec atomics Message-ID: <20090721162320.GA14423@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4A65BCC9 DOT 1020002 AT byu DOT net> <20090721135848 DOT GA2600 AT calimero DOT vinschen DOT de> <20090721140502 DOT GA11240 AT calimero DOT vinschen DOT de> <20090721141704 DOT GA26490 AT ednor DOT casa DOT cgf DOT cx> <20090721144003 DOT GB27613 AT calimero DOT vinschen DOT de> <20090721160512 DOT GA26791 AT ednor DOT casa DOT cgf DOT cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090721160512.GA26791@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.19 (2009-02-20) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Jul 21 12:05, Christopher Faylor wrote: > On Tue, Jul 21, 2009 at 04:40:03PM +0200, Corinna Vinschen wrote: > >On Jul 21 10:17, Christopher Faylor wrote: > >>I agree about waiting, but I think this is one for my TODO list. The > >>close_on_exec code is all mine, AFAIK. I reworked it all back in 1998 > >>or so, so it is pretty fresh in my mind. > > > >I don't think there's a lot to do in close_on_exec code itself related > >to this. There is no need to call set_close_on_exec at all, rather the > >fhandler should create the handle not inheritable in the first place. > >That goes for open as well as fcntl. Time to add Linux' dup3 call, I > >guess :) > > There is a lot to deal with here because: > > % grep ::set_close_on_exec *.cc > fhandler.cc:fhandler_base::set_close_on_exec (bool val) > fhandler_console.cc:fhandler_console::set_close_on_exec (bool val) > fhandler_console.cc: fhandler_base::set_close_on_exec (val); > fhandler_socket.cc:fhandler_socket::set_close_on_exec (bool val) > fhandler_socket.cc: fhandler_base::set_close_on_exec (val); > fhandler_tape.cc:fhandler_dev_tape::set_close_on_exec (bool val) > fhandler_tape.cc: fhandler_dev_raw::set_close_on_exec (val); > fhandler_tty.cc:fhandler_tty_common::set_close_on_exec (bool val) > fhandler_windows.cc:fhandler_windows::set_close_on_exec (bool val) > fhandler_windows.cc: fhandler_base::set_close_on_exec (val); > > and even more importantly: > > % grep '^fhandler[a-z_0-9]*::dup' *.cc > fhandler.cc:fhandler_base::dup (fhandler_base *child) > fhandler_clipboard.cc:fhandler_dev_clipboard::dup (fhandler_base * child) > fhandler_console.cc:fhandler_console::dup (fhandler_base *child) > fhandler_dsp.cc:fhandler_dev_dsp::dup (fhandler_base * child) > fhandler_fifo.cc:fhandler_fifo::dup (fhandler_base *child) > fhandler_floppy.cc:fhandler_dev_floppy::dup (fhandler_base *child) > fhandler_mem.cc:fhandler_dev_mem::dup (fhandler_base *child) > fhandler_random.cc:fhandler_dev_random::dup (fhandler_base *child) > fhandler_raw.cc:fhandler_dev_raw::dup (fhandler_base *child) > fhandler_registry.cc:fhandler_registry::dup (fhandler_base *child) > fhandler_serial.cc:fhandler_serial::dup (fhandler_base *child) > fhandler_socket.cc:fhandler_socket::dup (fhandler_base *child) > fhandler_tape.cc:fhandler_dev_tape::dup (fhandler_base *child) > fhandler_tty.cc:fhandler_tty_slave::dup (fhandler_base *child) > fhandler_tty.cc:fhandler_pty_master::dup (fhandler_base *child) > fhandler_virtual.cc:fhandler_virtual::dup (fhandler_base * child) > pipe.cc:fhandler_pipe::dup (fhandler_base *child) > > I was thinking about a way of collapsing most of those into one generic > call. But not for 1.7.1, obviously. Yes, but that's a different problem. Your work on set_close_on_exec does not touch open(O_CLOEXEC). The O_CLOEXEC stuff doesn't need to call set_close_on_exec at all. Granted, using it would be a simple way to implement O_CLOEXEC, but creating the handles inheritable vs. not inheritable in the first place is the more correct solution. Talking about dup3/fcntl(F_DUPFD_CLOEXEC), that's of course another story. I guess we should just split it between these two items. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple