From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EVuJt-0004PE-Vq for garchives@archives.gentoo.org; Sat, 29 Oct 2005 17:16:42 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j9THG4jf002065; Sat, 29 Oct 2005 17:16:04 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j9THG3hY030343 for ; Sat, 29 Oct 2005 17:16:03 GMT Received: from zh034158.ppp.dion.ne.jp ([222.3.34.158] helo=opteron246.suzuki-stubbs.home) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EVuJH-0002VH-53 for gentoo-portage-dev@lists.gentoo.org; Sat, 29 Oct 2005 17:16:03 +0000 Received: by opteron246.suzuki-stubbs.home (Postfix, from userid 1000) id A17CF248ADB; Sun, 30 Oct 2005 02:17:07 +0900 (JST) From: Jason Stubbs To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [5/7] portage_exec cleanups Date: Sun, 30 Oct 2005 02:17:07 +0900 User-Agent: KMail/1.8.92 References: <200510231545.16596.jstubbs@gentoo.org> <20051029160410.GO24883@nightcrawler> <200510300140.41639.jstubbs@gentoo.org> In-Reply-To: <200510300140.41639.jstubbs@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_T66YDt7hitu0mzJ" Message-Id: <200510300217.07518.jstubbs@gentoo.org> X-Archives-Salt: b788772d-a8ce-4282-be76-c88b0970f800 X-Archives-Hash: db57e3db6e900251055681240f64f874 --Boundary-00=_T66YDt7hitu0mzJ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sunday 30 October 2005 01:40, Jason Stubbs wrote: > Given the threading comment, I'd be agreeable to this. However, the spawn > of tee would have to specifically close the write side of the pipe when > unknown FDs aren't closed. Is having two extra paramaters, close_fds (a > list) and close_all_fds (a bool), to spawn okay? Okay. I'll back down on the closing/leaving unknown fds debate. The attached patch removes the usage of unused_fds introduced by 4/7, removes the unnecessary closing in the revised 3/7 and fixes two bugs in the detection of max_fd_limit. -- Jason Stubbs --Boundary-00=_T66YDt7hitu0mzJ Content-Type: text/x-diff; charset="utf-8"; name="05-bulk-fd-closing-take2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="05-bulk-fd-closing-take2.patch" --- portage_exec.py.orig 2005-10-30 02:05:50.000000000 +0900 +++ portage_exec.py 2005-10-30 02:08:03.000000000 +0900 @@ -11,11 +11,8 @@ try: import resource - max_fd_limit=resource.getrlimit(RLIMIT_NOFILE) -except SystemExit, e: - raise -except: - # hokay, no resource module. + max_fd_limit=resource.getrlimit(resource.RLIMIT_NOFILE)[1] +except ImportError: max_fd_limit=256 spawned_pids = [] @@ -83,7 +80,7 @@ mypid=[] if logfile: pr,pw=os.pipe() - mypid.extend(spawn(('tee','-i','-a',logfile),returnpid=True,fd_pipes={0:pr,1:fd_pipes[1],2:fd_pipes[2]},fd_unused=[pw])) + mypid.extend(spawn(('tee','-i','-a',logfile),returnpid=True,fd_pipes={0:pr,1:fd_pipes[1],2:fd_pipes[2]})) os.close(pr) fd_pipes[1]=pw fd_pipes[2]=pw @@ -95,22 +92,15 @@ mypid.append(os.fork()) if mypid[-1] == 0: my_pipes = {} - close_pipes = {} for x in fd_pipes: my_pipes[x] = os.dup(fd_pipes[x]) - close_pipes[fd_pipes[x]] = True - for x in close_pipes: - os.close(x) for x in my_pipes: os.dup2(my_pipes[x], x) - os.close(my_pipes[x]) - for x in range(0,max_fd_limit): + for x in range(max_fd_limit): if x not in trg_fd: - try: + try: os.close(x) - except SystemExit, e: - raise - except: + except OSError: pass # note this order must be preserved- can't change gid/groups if you change uid first. if gid: --Boundary-00=_T66YDt7hitu0mzJ-- -- gentoo-portage-dev@gentoo.org mailing list