Path: csiph.com!usenet.pasdenom.info!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!87.79.20.101.MISMATCH!newsreader4.netcologne.de!news.netcologne.de!bcyclone05.am1.xlned.com!bcyclone05.am1.xlned.com!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.003 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'heavily': 0.04; 'tries': 0.05; 'executed': 0.07; 'subject:file': 0.07; 'happen.': 0.09; 'naturally': 0.09; 'zero.': 0.09; 'cc:addr:python-list': 0.10; 'wed,': 0.15; '(given': 0.16; 'all?': 0.16; 'descriptor.': 0.16; 'descriptors': 0.16; 'fds': 0.16; 'forking': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'kernel.': 0.16; 'reason.': 0.16; 'slice.': 0.16; 'ui,': 0.16; 'wrote:': 0.16; 'shell': 0.18; 'cc:2**0': 0.21; 'cc:addr:python.org': 0.21; "user's": 0.22; '2015': 0.23; 'file.': 0.24; 'header:In-Reply-To:1': 0.24; 'linux': 0.26; 'error': 0.27; 'disk': 0.27; 'message-id:@mail.gmail.com': 0.28; "doesn't": 0.28; 'subject:/': 0.29; 'parent': 0.29; 'certainly': 0.31; 'code': 0.31; "can't": 0.32; 'system,': 0.32; 'holds': 0.32; 'returned': 0.32; 'common': 0.33; 'lets': 0.33; 'open': 0.33; 'editor': 0.34; 'file': 0.34; 'received:google.com': 0.34; 'done': 0.35; 'something': 0.35; 'really': 0.35; "isn't": 0.35; 'but': 0.36; 'being': 0.36; 'except': 0.36; 'there': 0.36; 'child': 0.36; 'closing': 0.36; 'loaded': 0.36; 'should': 0.37; 'subject:: ': 0.37; 'pm,': 0.39; 'whatever': 0.39; 'does': 0.39; 'seem': 0.39; 'why': 0.40; 'your': 0.60; 'close': 0.61; 'between': 0.65; 'results': 0.66; 'situation': 0.67; 'subject: & ': 0.73; 'child,': 0.84; 'chrisa': 0.84; 'much,': 0.84; 'to:none': 0.90; 'instantly': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=Q6RZA1RlBxmPWz1dQbp4cEp8F0KOQyHVC6EgkB7W2lQ=; b=qU5egIS1eCGSlLQeihQkNNTOE3W32INdZVL+FKSIeMie1BpxzZJvjPkRgjVjyQPyM5 xQMYt1eE5qR88YhqCK+7wb8+iGrM+ttE9ufr7JdY/C9cDNnBXaXRhDtez8u6f7+NFmkg vVSKFxyr8GK89YOaew/r62pspDtF22TvHcKuADx3HR5hpgOhW9vuRcIR0ulAxklUYgBl xtaBaThuSVDlVxnt2XsPGOIjn0aqeX97uGX/qlfcoaxx6UZgOFSkvJTgaO2teG7ZpPES Br87E8/5SQaIlUYuoXb4L6SDfe5I6+SlCjC7dYA4GbOEtEXfCzu2OU/Wg8w8mZpvs/7q /O7Q== MIME-Version: 1.0 X-Received: by 10.50.43.196 with SMTP id y4mr26898465igl.14.1433338343821; Wed, 03 Jun 2015 06:32:23 -0700 (PDT) In-Reply-To: <1433337679.1493926.285725793.69D6B33F@webmail.messagingengine.com> References: <87pp5eksnc.fsf@universite-de-strasbourg.fr.invalid> <87eglt7u5i.fsf@elektro.pacujo.net> <87lhg1lt00.fsf@universite-de-strasbourg.fr.invalid> <87a8wh7nq6.fsf@elektro.pacujo.net> <87d21dl0jc.fsf@universite-de-strasbourg.fr.invalid> <877frl6xxj.fsf@elektro.pacujo.net> <556eee15$0$12975$c3e8da3$5496439d@news.astraweb.com> <878uc1567j.fsf@elektro.pacujo.net> <87wpzl3pnn.fsf@elektro.pacujo.net> <1433337679.1493926.285725793.69D6B33F@webmail.messagingengine.com> Date: Wed, 3 Jun 2015 23:32:23 +1000 Subject: Re: fork/exec & close file descriptors From: Chris Angelico Cc: "python-list@python.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 33 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1433338346 news.xs4all.nl 2917 [2001:888:2000:d::a6]:47502 X-Complaints-To: abuse@xs4all.nl X-Received-Bytes: 5840 X-Received-Body-CRC: 2186796161 Xref: csiph.com comp.lang.python:91963 On Wed, Jun 3, 2015 at 11:21 PM, wrote: > On Wed, Jun 3, 2015, at 09:08, Marko Rauhamaa wrote: >> random832@fastmail.us: >> >> > Why does the child process need to report the error at all? The parent >> > process will find out naturally when *it* tries to close the same file >> > descriptor. >> >> That's not how it goes. >> >> File descriptors are reference counted in the Linux kernel. Closes are >> no-ops except for the last one that brings the reference count to zero. >> >> If the parent should close the file before the child, no error is >> returned to the parent. > > Why would the parent close it before the child? Your scenario doesn't > seem to have anything to do with how people actually use subprocesses. Write an editor that opens a file and holds it open until the user's done with it. Have something that lets you shell out for whatever reason. Then trigger the shell-out, and instantly SIGSTOP the child process, before it does its work - or just have a really heavily loaded system, so it can't get a time slice. Now close the file in the UI, which results in the file being closed in the parent. Right, now let the child run... and there it goes, closing the file. Mightn't be a common situation (given that the amount of code executed between forking and closing FDs is not going to be much, and isn't going to involve reading from disk or anything), but it can certainly happen. ChrisA